Date: Sun, 08 Sep 2024 19:09:41 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 281279] nfscl: panic: MSan: Uninitialized stack memory in nfscl_cberrmap Message-ID: <bug-281279-227-3IrDxDVkkU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-281279-227@https.bugs.freebsd.org/bugzilla/> References: <bug-281279-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281279 Alan Somers <asomers@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #4 from Alan Somers <asomers@FreeBSD.org> --- I think I've found the source of the problem: Firstly, my environment is a 15.0 client and a 14.1 server. The client uses nfs 4.2 for /usr/home and I run nfsuserd on both client and server. I have= no NFS tunables set on the client. What happens is that: 1) When I run "whoami", my shell does an append write to /usr/home/somers/.local/share/fish/fish_history 2) ncl_writerpc allocate "struct nfsvattr nfsva" on the stack, on its first line, but does not initialize it. 3) The AppendWrite RPC returns from the server. Wireshark shows that the compound RPC includes SEQUENCE, PUTFH, GETATTR, VERIFY, WRITE, and GETATTR.= =20 But the attr masks for neither GETATTR contain Owner.=20=20 4) So nfsv4_loadattr returns without initializing nap->na_uid . Note that = if I insert logic to set na_uid to 666 in step 2, it is still equal to 666 here. 5) control returns two levels up the stack back to ncl_writerpc 6) which calls nfscl_loadattrcache. At line 522 that function calls NFSBCO= PY to actually copy the attributes into NFS's attribute cache, and at that poi= nt na_uid is still uninitialized. Later, the shell stat()s the fish_history file. That reads the uninitializ= ed na_uid attribute from NFS's attribute cache, triggering the MSAN panic abov= e. But what can we do about it? I have a patch that sets na_uid=3Dna_gid=3DVNO= VAL in nfsv4_loadattr. That makes the MSAN warnings go away. And yet, I'm not convinced that it's the correct solution. After all, I've never actually s= een the wrong uid or gid displayed by "ls", which suggests that it's getting set somehow, even if MSAN doesn't know it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-281279-227-3IrDxDVkkU>