Page MenuHomeFreeBSD

vfs_lookup: Allow PATH_MAX-1 symlinks
ClosedPublic

Authored by cem on Oct 4 2017, 3:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 21, 3:08 AM
Unknown Object (File)
Oct 7 2024, 4:22 AM
Unknown Object (File)
Oct 7 2024, 2:42 AM
Unknown Object (File)
Sep 17 2024, 6:15 AM
Unknown Object (File)
Sep 17 2024, 6:15 AM
Unknown Object (File)
Sep 17 2024, 6:15 AM
Unknown Object (File)
Sep 17 2024, 6:03 AM
Unknown Object (File)
Sep 15 2024, 11:51 AM
Subscribers
None

Details

Summary

Previously, symlinks in FreeBSD were artificially limited to PATH_MAX-2.

Add a short test case to verify the change.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/kern/vfs_lookup.c
513 โ†—(On Diff #33694)

Suppose that ndp->ni_pathlen == 0 and we use cnp->cn_pnbuf for keeping the symlink content and that linklen == MAXPATHLEN. cn_pnbuf has exactly MAXPATHLEN bytes length. This line would assign zero to one byte after the buffer end, isn't it ?

sys/kern/vfs_lookup.c
513 โ†—(On Diff #33694)

ni_pathlen includes the trailing nul byte, which is the reason the above modified calculation was wrong.

It comes from the *done parameter of copystr() / copyinstr(), with len=MAXPATHLEN (lines ~324-328). The manual page describes copyinstr():

The copyinstr() function copies a NUL-terminated string, at most len
bytes long, from user-space address uaddr to kernel-space address kaddr.
The number of bytes actually copied, including the terminating NUL, is
returned in *done (if done is non-NULL).

Therefore, I do not believe ni_pathlen can ever be zero. An empty string will have an ni_pathlen of 1.

Therefore, linklen is restricted to MAXPATHLEN-1 (instead of MAXPATHLEN-2) by the changed line, and there is no problem assigning to cn_pnbuf[linklen] on the line you have noted.

This revision is now accepted and ready to land.Oct 4 2017, 4:51 PM
This revision was automatically updated to reflect the committed changes.