Date: Mon, 28 Jul 2008 13:37:15 +0200 From: "Alexander Leidinger" <Alexander@Leidinger.net> To: "Roman Divacky" <rdivacky@freebsd.org> Cc: freebsd-emulation@freebsd.org, Chagin Dmitry <chagin.dmitry@gmail.com> Subject: Re: kern/117010: [linux] linux_getdents() get somethinng like buffer overflow Message-ID: <20080728133715.1670576xbp279u04@webmail.leidinger.net> In-Reply-To: <20080728102715.GA78842@freebsd.org> References: <200807250700.m6P70FSF036132@freefall.freebsd.org> <20080726091045.4c617dc7@deskjail> <alpine.BSF.1.10.0807271958020.3912@ora.chd.net> <20080728085403.58063b2gbchdjtic@webmail.leidinger.net> <alpine.BSF.1.10.0807281300060.1453@ora.chd.net> <20080728102715.GA78842@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Roman Divacky" <rdivacky@freebsd.org> (from Mon, 28 Jul 2008 =20 12:27:15 +0200): > > [snip of technical discussion] > > while I agree with the attitude that it should be fixed properly, we are > in a situation where a simple patch fixes a problem. and the fix is correc= t. > > I think we should just commit Dmitry's patch and then talk about how =20 > to change > linux_getdents() further. I looked at the Linux code and the =20 > alignment is really > +2 for 32bit and +1 for 64 bit as Dmitry's patch does. That's not the alignment, that's some simple but mandatory padding (a =20 comment should be written there what this is, for the "1" it's the =20 null byte of the name, for the second "1" (in the case of using "2"), =20 I don't know yet what it is). I haven't checked yet if the size =20 calculation (which has the wrong macro name ALIGN, it doesn't align, =20 it just used in the align process) does the right thing on 64bit =20 (padding to a 64bit boundary, so that the next entry starts at a 64bit =20 boundary =3D alignment of the structure). > do you guys agree that fixing the problem the simplest/fastest way =20 > now and then > changing other things is the correct way? It may fix the problem of some specific test cases, but I'm not sure =20 it fixes all use cases. I see this as a partial fix to allow people to =20 do some more tests in other areas of the linuxulator while someone is =20 looking into a complete fix. I don't object if you commit it, but =20 don't think dirent is bugfree after this (I would call it a temporary =20 workaround). Bye, Alexander. --=20 A day without sunshine .... is like ... night! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080728133715.1670576xbp279u04>