Date: Tue, 26 Apr 2016 17:18:04 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Kristof Provost <kp@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r298664 - head/sys/fs/msdosfs Message-ID: <20160426211804.GB13055@mutt-hardenedbsd> In-Reply-To: <2190C480-1B7A-47F8-BFB4-D7C8E6F25385@FreeBSD.org> References: <201604262036.u3QKaWto038435@repo.freebsd.org> <20160426210138.GA13055@mutt-hardenedbsd> <2190C480-1B7A-47F8-BFB4-D7C8E6F25385@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2016 at 11:05:38PM +0200, Kristof Provost wrote: >=20 > > On 26 Apr 2016, at 23:01, Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > >=20 > > On Tue, Apr 26, 2016 at 08:36:32PM +0000, Kristof Provost wrote: > >> Author: kp > >> Date: Tue Apr 26 20:36:32 2016 > >> New Revision: 298664 > >> URL: https://svnweb.freebsd.org/changeset/base/298664 > >>=20 > >> Log: > >> msdosfs: Prevent buffer overflow when expanding win95 names > >>=20 > >> In win2unixfn() we expand Windows 95 style long names. In some cases = that > >> requires moving the data in the nbp->nb_buf buffer backwards to make = room. That > >> code failed to check for overflows, leading to a stack overflow in wi= n2unixfn(). > >>=20 > >> We now check for this event, and mark the entire conversion as failed= in that > >> case. This means we present the 8 character, dos style, name instead. > >>=20 > >> PR: 204643 > >> Differential Revision: https://reviews.freebsd.org/D6015 > >=20 > > Will this be MFC'd? Since it's triggerable as non-root, should this have > > a CVE? Though the commit log shows technical comments, it doesn't show > > related security information. >=20 > Yes, I???ll put MFCing this on my todo list. >=20 > I have to admit that I???ve not given the security implications much thou= ght. The bug has always been caught by the stack canary on my test systems,= without that it could potentially be quite dangerous. > (Given constraints of having to be able to mount arbitrary file systems a= s non-root of course.) >=20 > Regards, > Kristof Was secteam@ even involved, then? Seems like a user-facing kernel buffer overflow ought to have involved secteam@. Also, the differential revision link you posted is incorrect. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXH9sKAAoJEGqEZY9SRW7udGIP/0Z1hLdz4aZtSuYVGckBWSO8 g+sRUt3DV37xHWnQelFwxSE3xD4umDP9aGvO4PVkTmsVIdeRb9In7NZqawXrEV7U JZM/0r7r71zstnZnek45tyYUqwQammgcshDuOb2r0PdIRb/Id7cb+QAssqC+qVql amVaj/uLCkkIbbIUqYm4jVpuG1SsZYJvzHHngI8p9kpKMbHW5wY8Bg0/4k4PIefB 8KTYypJ8r+HMFYSsYL30u4YVasmF+xyg42Z5qR1vExFtwzrdiRhpG0bkFgXPy/hs LQ+8uH2KNKeRrcAjQBkVA9QeDoVMoblwVN8W7bXRGl0yyxxVsF6PV6u1vP7vF/Oz HLPje8o/RvuCLzAajyMqfTnDqDRceS7NDiPLMr0Fum/kA8wMRXFzpgNlHOtEEAnQ vUJRc/EjmwtRW+87lsfcrn6aP3XZr9LJFHB3LnWWtkytDC3quQUG87qud9FxWQcR SdHNq5radp9x/xtU4j3jJT1MEc7h5ru9jw46OPtAqyppn3R0HmdC03jkI1AIImpS Qs5S6I0HLB1Gkhs+IeXn1zWfypBLBBv4wCf7R6qXJcg38J6OqchSifni2txrifh0 Dw8oGNwyig2g7Rv4Dm27gtGRSVx6x78ckVhipaqq63NVU42k4qyGP6UMEdmqih8C yi5EWIJdj4hvVVWkaLzA =N5v9 -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160426211804.GB13055>