On Tue, Apr 26, 2016 at 11:05:38PM +0200, Kristof Provost wrote: > > > On 26 Apr 2016, at 23:01, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > 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 > >> > >> Log: > >> msdosfs: Prevent buffer overflow when expanding win95 names > >> > >> 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 > >> win2unixfn(). > >> > >> 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. > >> > >> PR: 204643 > >> Differential Revision: https://reviews.freebsd.org/D6015 > > > > 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. > > Yes, I???ll put MFCing this on my todo list. > > I have to admit that I???ve not given the security implications much thought. > 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 as > non-root of course.) > > 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, -- Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
