Chris Mason wrote:
>
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
> >
>
> Here is a patch against our 2.4 code (3.6.25) that does the
> same as the patch posted for 3.5.29:
>
>
Chris Mason wrote:
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
Here is a patch against our 2.4 code (3.6.25) that does the
same as
On Wed, Jan 10, 2001 at 06:03:53PM +0100, Stefan Traby wrote:
> Really, the 255-limit is essential as long as "struct dirent/64" has
> d_name[255] hard coded. Somebody should send Drepper a patch;
sorry, d_name[256], not 255 in both, glibc and kernel...
--
Stefan
-
To unsubscribe from
On Wed, Jan 10, 2001 at 07:02:08PM +0300, Vladimir V. Saveliev wrote:
> Hmm, wouldn't it make existing long named files unreachable?
This is not of primary interest. Security first.
The only way to recover those files secure without risking a crash
is maybe to let fsck rename those long files
On Wed, Jan 10, 2001 at 12:47:17AM -0500, Alexander Viro wrote:
> Chris, I seriously suspect that it's not that simple (read: trace is a
> BS). 0x20b is just too large for filldir().
[..]
> and we don't trigger them... Fsck knows. copy_to_user() and put_user() should
> not be able to screw the
On Wednesday, January 10, 2001 07:02:08 PM +0300 "Vladimir V. Saveliev"
<[EMAIL PROTECTED]> wrote:
> Hi
>
> Chris Mason wrote:
>
>> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann
>> <[EMAIL PROTECTED]> wrote:
>>
>> >>> EIP; c013f911<=
>> > Trace; c013f706
>> > Trace;
Hi
Chris Mason wrote:
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
>
> The buffer reiserfs is sending to filldir is big enough for
> the huge file name, so I think the real
On Wed, Jan 10, 2001 at 03:56:32AM +0300, Vladimir V. Saveliev wrote:
> Hi
>
> Marc Lehmann wrote:
>
> > We are still investigating, but there seems to be a major security problem
>
> Hmm,
> mkdir "$(perl -e 'print "x" x 768')"
> ls
> echo *
>
> works here as it should. (2.2.18 and
> The best workaround at this time seems to be to uninstall reiserfs
> completely or not allow any user access (even indirect) to these volumes.
> While this individual bug might be easy to fix, we believe that other,
> similar bugs should be easy to find so reiserfs should not be trusted (it
>
Hi
Chris Mason wrote:
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
The buffer reiserfs is sending to filldir is big enough for
the huge
On Wednesday, January 10, 2001 07:02:08 PM +0300 "Vladimir V. Saveliev"
[EMAIL PROTECTED] wrote:
Hi
Chris Mason wrote:
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann
[EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
On Wed, Jan 10, 2001 at 12:47:17AM -0500, Alexander Viro wrote:
Chris, I seriously suspect that it's not that simple (read: trace is a
BS). 0x20b is just too large for filldir().
[..]
and we don't trigger them... Fsck knows. copy_to_user() and put_user() should
not be able to screw the kernel
On Wed, Jan 10, 2001 at 07:02:08PM +0300, Vladimir V. Saveliev wrote:
Hmm, wouldn't it make existing long named files unreachable?
This is not of primary interest. Security first.
The only way to recover those files secure without risking a crash
is maybe to let fsck rename those long files
On Wed, Jan 10, 2001 at 06:03:53PM +0100, Stefan Traby wrote:
Really, the 255-limit is essential as long as "struct dirent/64" has
d_name[255] hard coded. Somebody should send Drepper a patch;
sorry, d_name[256], not 255 in both, glibc and kernel...
--
Stefan
-
To unsubscribe from this
The best workaround at this time seems to be to uninstall reiserfs
completely or not allow any user access (even indirect) to these volumes.
While this individual bug might be easy to fix, we believe that other,
similar bugs should be easy to find so reiserfs should not be trusted (it
On Wed, Jan 10, 2001 at 03:56:32AM +0300, Vladimir V. Saveliev wrote:
Hi
Marc Lehmann wrote:
We are still investigating, but there seems to be a major security problem
Hmm,
mkdir "$(perl -e 'print "x" x 768')"
ls
echo *
works here as it should. (2.2.18 and reiserfs-3.5.29)
cat
Why not use the limits from instead?
-d
Chris Mason wrote:
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
>
> The buffer reiserfs is sending to filldir is big enough for
> the
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>>> EIP; c013f911<=
> Trace; c013f706
> Trace; c0136e01
>
Here is a patch against our 2.4 code (3.6.25) that does the
same as the patch posted for 3.5.29:
-chris
---
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>>> EIP; c013f911<=
> Trace; c013f706
> Trace; c0136e01
The buffer reiserfs is sending to filldir is big enough for
the huge file name, so I think the real fix should be done in VFSland.
But,
Hi
Marc Lehmann wrote:
> We are still investigating, but there seems to be a major security problem
> in at least some versions of reiserfs. Since reiserfs is shipped with
> newer versions of SuSE Linux and the problem is too easy to reproduce and
> VERY dangerous I think alerting people to
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
The buffer reiserfs is sending to filldir is big enough for
the huge file name, so I think the
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
Here is a patch against our 2.4 code (3.6.25) that does the
same as the patch posted for
Why not use the limits from linux/limits.h instead?
-d
Chris Mason wrote:
On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann [EMAIL PROTECTED] wrote:
EIP; c013f911 filldir+20b/221 =
Trace; c013f706 filldir+0/221
Trace; c0136e01 reiserfs_getblk+2a/16d
The buffer
Hi
Marc Lehmann wrote:
We are still investigating, but there seems to be a major security problem
in at least some versions of reiserfs. Since reiserfs is shipped with
newer versions of SuSE Linux and the problem is too easy to reproduce and
VERY dangerous I think alerting people to this
24 matches
Mail list logo
