Page MenuHomeFreeBSD

vfs: Add some assertions around various name length limits
ClosedPublic

Authored by markj on Fri, Mar 26, 4:13 PM.

Details

Summary

There is some code in UFS and devfs that assumes that one can safely
copy a name component into a buffer of size MAXNAMLEN or SPECNAMELEN,
respectively, while the limit on name components is NAME_MAX. All of
these constants are equal, but one may try changing them (I know that
OneFS has done this, for instance). Add a seatbelt to help catch cases
where this isn't done correctly.

Reported by: Alexey Kulaev <alex.qart@gmail.com>

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj requested review of this revision.Fri, Mar 26, 4:13 PM

Can you show what do you mean by devfs reference? SPECNAMELEN was only bumped very recently, before 2019 it was 63 bytes.

SPECNAMELEN actually means the whole path from the devfs root to the special node, including all intermediate directories, if any. This is the path stored in struct cdev, and supported e.g. by devfs_fqpn().

This revision is now accepted and ready to land.Fri, Mar 26, 4:35 PM
In D29431#659347, @kib wrote:

Can you show what do you mean by devfs reference? SPECNAMELEN was only bumped very recently, before 2019 it was 63 bytes.

SPECNAMELEN actually means the whole path from the devfs root to the special node, including all intermediate directories, if any. This is the path stored in struct cdev, and supported e.g. by devfs_fqpn().

I was indeed looking at devfs_fqpn(), but I see now that we have sufficient checking there. I was just looking for other examples where we copy a name component into a buffer as in, e.g., ufs_whiteout().

I will just remove the SPECNAMELEN reference, since as you not it is a maximum for the whole path rather than a name component.

Limit the check to MAXNAMLEN. I will edit the commit message to remove message
of devfs.

This revision now requires review to proceed.Fri, Mar 26, 4:56 PM
This revision is now accepted and ready to land.Fri, Mar 26, 5:07 PM