Page MenuHomeFreeBSD

vfs: handle file mounts in vn_fullpath_hardlink()
Needs ReviewPublic

Authored by nick_spun.io on Sat, Jul 11, 11:22 PM.
Tags
None
Referenced Files
F162424142: D58178.id181803.diff
Mon, Jul 13, 3:23 AM
Unknown Object (File)
Sun, Jul 12, 12:15 AM
Subscribers

Details

Reviewers
kib
markj
olce
Summary

For file mounts, lookup returns the mount root vnode with ni_dvp set
to vp_crossmp, which cannot be used to walk up the directory tree.
execve(2) of such a file stores vp_crossmp as p_textdvp, and a later
kern.proc.pathname query on the process descends into it, tripping
VNPASS(vp->v_type == VDIR || VN_IS_DOOMED(vp)) in vn_fullpath_dir()
on INVARIANTS kernels. This is readily triggered by www/foreign-cdm,
which execs its Widevine worker from a single-file nullfs mount: any
subsequent htop or procstat -b against that process panics the box.

Resolve file mounts in vn_fullpath_hardlink() itself via the covered
vnode, the same way a1d74b2dab78 handled realpath(2); the resulting
path is unambiguous since file mounts require a link count of 1. This
covers all callers: kern.proc.pathname, AT_EXECPATH for a relative
execve of a file mount, and vn_path_to_global_path_hardlink(). Drop
the now-redundant special case in kern___realpathat().

Since vn_fullpath() resolves into its own MAXPATHLEN buffer, check the
result against the caller-supplied size and return ENAMETOOLONG when
it does not fit, as the dropped special case did via the check in
kern___realpathat(); without this, __realpathat(2) would copy out past
the size given by the caller. Take the branch before the size
validation and work buffer allocation so that undersized buffers keep
returning ENAMETOOLONG rather than EINVAL and the work buffer is not
allocated just to be freed.

PR: 282596
Signed-off-by: Nick Price <nick@spun.io>

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 74748
Build 71631: arc lint + arc unit

Event Timeline

This happens more than once, as indicated in e.g. d53633bfcf24a3eb37. I wonder of we should fix lookup/namei for the case of regular mount, once and for all. See D58191 which is only a draft, which is not tested.

sys/kern/vfs_cache.c
3846

At least you need to recheck the condition after the vnode is locked, to see that it is really the root still.

In D58178#1334439, @kib wrote:

This happens more than once, as indicated in e.g. d53633bfcf24a3eb37. I wonder of we should fix lookup/namei for the case of regular mount, once and for all. See D58191 which is only a draft, which is not tested.

I think a structural fix is definitely the way to go otherwise these conditions will probably keep popping up - I'll run D58191 for a while and see if anything pops up

Been trying to figure out some structural fixes as well to prevent/mitigate assumptions that mount roots are directories (nullfs can mount files as well) but there doesn't seem to be a real "silver bullet" fix I can identify

I suspect that even after D58191 some fix along these lines is needed. The fullpath routines need to be prepared that the parent is not VREG.

Could you confirm this?