Date: Sun, 19 Dec 2021 16:30:58 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 260546] nfsv4_loadattr() can pass huge sizes to malloc() Message-ID: <bug-260546-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260546 Bug ID: 260546 Summary: nfsv4_loadattr() can pass huge sizes to malloc() Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: rtm@lcs.mit.edu In the NFSATTRBIT_OWNERGROUP code in nfsv4_loadattr(): NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); j =3D fxdr_unsigned(int, *tl); if (j < 0) { error =3D NFSERR_BADXDR; goto nfsmout; } attrsum +=3D (NFSX_UNSIGNED + NFSM_RNDUP(j)); if (j > NFSV4_SMALLSTR){ cp =3D malloc(j + 1, M_NFSSTRING, M_WAITOK); First, a big j can cause this code to allocate a few GB of memory, enough to cause my modest test machine to run out. Second, the "if (j < 0)" along with the "j + 1" means that if the RPC message contains j =3D 0x7fffffff, malloc will be called with (size_t)(j+1) =3D (size_t)(0x80000000)=20 which is 0xffffffff80000000 if size_t is unsigned and 64 bits. This seems to cause malloc() to never return on my machine. --=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-260546-227>