Upper limit for sysctl fs.file-max
The normal default for fs.file-max (the maximum number of file structures) is 1/10240th of the available memory. However it seems to be possible to set fs.file-max to any value up to 2^64-1. While all 'large' values are effectively the same this seems rather excessive here. Problems arrive when any shell scripts (or anything else that only really has signed 64bit numbers) try to process values above 2^63-1 as these cause errors and/or other unexpected actions. ISTM that the values of a lot of sysctl parameters should be limited to avoid such problems. We've hit this because something is awry in the 5.0 kernel in ubuntu 19.04. Booting the failing userspace with a 5.1-rcx kernel is ok. Nothing looks wrong with the object code for the function that sets the default, and the last thing it does is divide by 10 so it is difficult for it to generate -1. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Thu, Apr 4, 2019 at 4:09 PM Christian Brauner wrote: > > On Wed, Apr 03, 2019 at 07:08:47PM +0200, Matteo Croce wrote: > > On Wed, Apr 3, 2019 at 6:40 PM Matteo Croce wrote: > > > > > > On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox wrote: > > > > > > > > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote: > > > > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner > > > > > wrote: > > > > > > Yeah, maybe but it still feels cleaner and more obvious to just add: > > > > > > > > > > > > static long long_zero; > > > > > > > > > > > > given that most callers actually seem to want an (unsigned) int. > > > > > > > > > > > > I don't have a strong opinion though so if others feel that it's > > > > > > just a > > > > > > waste of space consider it acked. > > > > > > > > > > > > > > > > Well, given that the value is zero, in this expectional case we could > > > > > avoid duplicating the symbol and save 4 bytes. > > > > > What the maintainers think? > > > > > > > > If we care about saving four bytes, we could just pass the address of > > > > ZERO_PAGE(0). > > > > > > That would work, work too, maybe it's a bit overkill. > > > int zero is always there and it's static, so enlarging it to long > > > should be a straightforward fix. > > > Obviously we can't do it for other numbers, but we can alias it just > > > for the zero case.. > > > > > > Regards, > > > > > > -- > > > Matteo Croce > > > per aspera ad upstream > > > > Anyway, I'm fine with both solutions, as I have other patches in the > > I think Matthew's idea gets us best of both worlds so I'd suggest to use > it and resend the patch. You likely want to Cc sta...@vger.kernel.org > since the original patch this fixes got backported by Greg quite a bit > since this was a rather long-standing issue. Please also Cc Andrew this > time since he's likely going to pick it up. > > Thanks for the patch! > Christian So you mean using page_address(ZERO_PAGE(0)) ? The idea is nice, but since struct ctl_table kern_table is declared as global variable, how can I assign it to the structure? GCC complains about 'initializer element is not constant', and ZERO_PAGE(0)->virtual only works if WANT_PAGE_VIRTUAL. Anyway, I'm preparing a treewide patch to move all "zero", "one" and "int_max" to three single, const variables in fs/proc/proc_sysctl.c as there are 200+ occourrences of them, so I'd rather keep this simple to have it easily backported to stable. -- Matteo Croce per aspera ad upstream
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 03, 2019 at 07:08:47PM +0200, Matteo Croce wrote: > On Wed, Apr 3, 2019 at 6:40 PM Matteo Croce wrote: > > > > On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox wrote: > > > > > > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote: > > > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner > > > > wrote: > > > > > Yeah, maybe but it still feels cleaner and more obvious to just add: > > > > > > > > > > static long long_zero; > > > > > > > > > > given that most callers actually seem to want an (unsigned) int. > > > > > > > > > > I don't have a strong opinion though so if others feel that it's just > > > > > a > > > > > waste of space consider it acked. > > > > > > > > > > > > > Well, given that the value is zero, in this expectional case we could > > > > avoid duplicating the symbol and save 4 bytes. > > > > What the maintainers think? > > > > > > If we care about saving four bytes, we could just pass the address of > > > ZERO_PAGE(0). > > > > That would work, work too, maybe it's a bit overkill. > > int zero is always there and it's static, so enlarging it to long > > should be a straightforward fix. > > Obviously we can't do it for other numbers, but we can alias it just > > for the zero case.. > > > > Regards, > > > > -- > > Matteo Croce > > per aspera ad upstream > > Anyway, I'm fine with both solutions, as I have other patches in the I think Matthew's idea gets us best of both worlds so I'd suggest to use it and resend the patch. You likely want to Cc sta...@vger.kernel.org since the original patch this fixes got backported by Greg quite a bit since this was a rather long-standing issue. Please also Cc Andrew this time since he's likely going to pick it up. Thanks for the patch! Christian
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 3, 2019 at 7:41 PM Kees Cook wrote:
>
> On Thu, Mar 28, 2019 at 6:03 AM Matteo Croce wrote:
> >
> > fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> > accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> > ("sysctl: handle overflow for file-max") assigns , which is an int,
> > to extra1, generating the following KASAN report.
> > Fix this by changing 'zero' to long, which does not need to be duplicated
> > like 'one' and 'one_ul' for two data types.
> >
> > ==
> > BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x2f9/0x600
> > Read of size 8 at addr 8233dc20 by task systemd/1
> >
> > CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc2-kvm+ #22
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> > ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
> > Call Trace:
> > print_address_description+0x67/0x23d
> > kasan_report.cold.3+0x1c/0x36
> > __do_proc_doulongvec_minmax+0x2f9/0x600
> > proc_doulongvec_minmax+0x3a/0x50
> > proc_sys_call_handler+0x11d/0x170
> > vfs_write+0xd7/0x200
> > ksys_write+0x93/0x110
> > do_syscall_64+0x57/0x140
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7f67d33e8804
> > Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48
> > 8d 05 f9 5e 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff
> > ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
> > RSP: 002b:7fffd9992ed8 EFLAGS: 0246 ORIG_RAX: 0001
> > RAX: ffda RBX: RCX: 7f67d33e8804
> > RDX: 0015 RSI: 5586ce2607b0 RDI: 0004
> > RBP: 7fffd9992f30 R08: c0c0 R09:
> > R10: R11: 0246 R12: 0004
> > R13: 0015 R14: 5586ce2607c4 R15: 7fffd9992f70
> >
> > The buggy address belongs to the variable:
> > 0x8233dc20
> >
> > Memory state around the buggy address:
> > 8233db00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
> > 8233db80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
> > >8233dc00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
> >^
> > 8233dc80: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> > 8233dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ==
> >
> > Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max")
> > Signed-off-by: Matteo Croce
> > ---
> > kernel/sysctl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index e5da394d1ca3..3e959d67d619 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -124,7 +124,7 @@ static int sixty = 60;
> >
> > static int __maybe_unused neg_one = -1;
> >
> > -static int zero;
> > +static long zero;
> > static int __maybe_unused one = 1;
> > static int __maybe_unused two = 2;
> > static int __maybe_unused four = 4;
>
> This seems okay to me; thanks for the fix! (I think it's fine to keep
> this merged instead of a distinct long_zero, as long as we're not
> seeing type warnings during the build.)
>
> Acked-by: Kees Cook
>
> -Kees
>
> --
> Kees Cook
No warnings with gcc version 8.3.1 20190223
CC kernel/sysctl.o
AR kernel/built-in.a
...
--
Matteo Croce
per aspera ad upstream
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Thu, Mar 28, 2019 at 6:03 AM Matteo Croce wrote:
>
> fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> ("sysctl: handle overflow for file-max") assigns , which is an int,
> to extra1, generating the following KASAN report.
> Fix this by changing 'zero' to long, which does not need to be duplicated
> like 'one' and 'one_ul' for two data types.
>
> ==
> BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x2f9/0x600
> Read of size 8 at addr 8233dc20 by task systemd/1
>
> CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc2-kvm+ #22
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
> Call Trace:
> print_address_description+0x67/0x23d
> kasan_report.cold.3+0x1c/0x36
> __do_proc_doulongvec_minmax+0x2f9/0x600
> proc_doulongvec_minmax+0x3a/0x50
> proc_sys_call_handler+0x11d/0x170
> vfs_write+0xd7/0x200
> ksys_write+0x93/0x110
> do_syscall_64+0x57/0x140
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f67d33e8804
> Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d
> 05 f9 5e 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77
> 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
> RSP: 002b:7fffd9992ed8 EFLAGS: 0246 ORIG_RAX: 0001
> RAX: ffda RBX: RCX: 7f67d33e8804
> RDX: 0015 RSI: 5586ce2607b0 RDI: 0004
> RBP: 7fffd9992f30 R08: c0c0 R09:
> R10: R11: 0246 R12: 0004
> R13: 0015 R14: 5586ce2607c4 R15: 7fffd9992f70
>
> The buggy address belongs to the variable:
> 0x8233dc20
>
> Memory state around the buggy address:
> 8233db00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
> 8233db80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
> >8233dc00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
>^
> 8233dc80: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 8233dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==
>
> Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max")
> Signed-off-by: Matteo Croce
> ---
> kernel/sysctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index e5da394d1ca3..3e959d67d619 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -124,7 +124,7 @@ static int sixty = 60;
>
> static int __maybe_unused neg_one = -1;
>
> -static int zero;
> +static long zero;
> static int __maybe_unused one = 1;
> static int __maybe_unused two = 2;
> static int __maybe_unused four = 4;
This seems okay to me; thanks for the fix! (I think it's fine to keep
this merged instead of a distinct long_zero, as long as we're not
seeing type warnings during the build.)
Acked-by: Kees Cook
-Kees
--
Kees Cook
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 3, 2019 at 6:40 PM Matteo Croce wrote: > > On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox wrote: > > > > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote: > > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner > > > wrote: > > > > Yeah, maybe but it still feels cleaner and more obvious to just add: > > > > > > > > static long long_zero; > > > > > > > > given that most callers actually seem to want an (unsigned) int. > > > > > > > > I don't have a strong opinion though so if others feel that it's just a > > > > waste of space consider it acked. > > > > > > > > > > Well, given that the value is zero, in this expectional case we could > > > avoid duplicating the symbol and save 4 bytes. > > > What the maintainers think? > > > > If we care about saving four bytes, we could just pass the address of > > ZERO_PAGE(0). > > That would work, work too, maybe it's a bit overkill. > int zero is always there and it's static, so enlarging it to long > should be a straightforward fix. > Obviously we can't do it for other numbers, but we can alias it just > for the zero case.. > > Regards, > > -- > Matteo Croce > per aspera ad upstream Anyway, I'm fine with both solutions, as I have other patches in the queue which depends on this fix. Regards, -- Matteo Croce per aspera ad upstream
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox wrote: > > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote: > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner > > wrote: > > > Yeah, maybe but it still feels cleaner and more obvious to just add: > > > > > > static long long_zero; > > > > > > given that most callers actually seem to want an (unsigned) int. > > > > > > I don't have a strong opinion though so if others feel that it's just a > > > waste of space consider it acked. > > > > > > > Well, given that the value is zero, in this expectional case we could > > avoid duplicating the symbol and save 4 bytes. > > What the maintainers think? > > If we care about saving four bytes, we could just pass the address of > ZERO_PAGE(0). That would work, work too, maybe it's a bit overkill. int zero is always there and it's static, so enlarging it to long should be a straightforward fix. Obviously we can't do it for other numbers, but we can alias it just for the zero case.. Regards, -- Matteo Croce per aspera ad upstream
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote: > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner wrote: > > Yeah, maybe but it still feels cleaner and more obvious to just add: > > > > static long long_zero; > > > > given that most callers actually seem to want an (unsigned) int. > > > > I don't have a strong opinion though so if others feel that it's just a > > waste of space consider it acked. > > > > Well, given that the value is zero, in this expectional case we could > avoid duplicating the symbol and save 4 bytes. > What the maintainers think? If we care about saving four bytes, we could just pass the address of ZERO_PAGE(0).
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner wrote:
>
> On Thu, Mar 28, 2019 at 02:03:06PM +0100, Matteo Croce wrote:
> > fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> > accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> > ("sysctl: handle overflow for file-max") assigns , which is an int,
> > to extra1, generating the following KASAN report.
> > Fix this by changing 'zero' to long, which does not need to be duplicated
> > like 'one' and 'one_ul' for two data types.
>
> Yeah, maybe but it still feels cleaner and more obvious to just add:
>
> static long long_zero;
>
> given that most callers actually seem to want an (unsigned) int.
>
> I don't have a strong opinion though so if others feel that it's just a
> waste of space consider it acked.
>
Well, given that the value is zero, in this expectional case we could
avoid duplicating the symbol and save 4 bytes.
What the maintainers think?
Cheers,
--
Matteo Croce
per aspera ad upstream
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Thu, Mar 28, 2019 at 02:03:06PM +0100, Matteo Croce wrote:
> fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> ("sysctl: handle overflow for file-max") assigns , which is an int,
> to extra1, generating the following KASAN report.
> Fix this by changing 'zero' to long, which does not need to be duplicated
> like 'one' and 'one_ul' for two data types.
Yeah, maybe but it still feels cleaner and more obvious to just add:
static long long_zero;
given that most callers actually seem to want an (unsigned) int.
I don't have a strong opinion though so if others feel that it's just a
waste of space consider it acked.
>
> ==
> BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x2f9/0x600
> Read of size 8 at addr 8233dc20 by task systemd/1
>
> CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc2-kvm+ #22
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
> Call Trace:
> print_address_description+0x67/0x23d
> kasan_report.cold.3+0x1c/0x36
> __do_proc_doulongvec_minmax+0x2f9/0x600
> proc_doulongvec_minmax+0x3a/0x50
> proc_sys_call_handler+0x11d/0x170
> vfs_write+0xd7/0x200
> ksys_write+0x93/0x110
> do_syscall_64+0x57/0x140
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f67d33e8804
> Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d
> 05 f9 5e 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77
> 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
> RSP: 002b:7fffd9992ed8 EFLAGS: 0246 ORIG_RAX: 0001
> RAX: ffda RBX: RCX: 7f67d33e8804
> RDX: 0015 RSI: 5586ce2607b0 RDI: 0004
> RBP: 7fffd9992f30 R08: c0c0 R09:
> R10: R11: 0246 R12: 0004
> R13: 0015 R14: 5586ce2607c4 R15: 7fffd9992f70
>
> The buggy address belongs to the variable:
> 0x8233dc20
>
> Memory state around the buggy address:
> 8233db00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
> 8233db80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
> >8233dc00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
>^
> 8233dc80: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 8233dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==
>
> Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max")
Next time, please take the time to Cc the author of the Fixes patch as
well whose commit this is fixing right away.
> Signed-off-by: Matteo Croce
> ---
> kernel/sysctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index e5da394d1ca3..3e959d67d619 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -124,7 +124,7 @@ static int sixty = 60;
>
> static int __maybe_unused neg_one = -1;
>
> -static int zero;
> +static long zero;
> static int __maybe_unused one = 1;
> static int __maybe_unused two = 2;
> static int __maybe_unused four = 4;
> --
> 2.20.1
>
Re: [PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
On Thu, Mar 28, 2019 at 2:03 PM Matteo Croce wrote:
>
> fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> ("sysctl: handle overflow for file-max") assigns , which is an int,
> to extra1, generating the following KASAN report.
> Fix this by changing 'zero' to long, which does not need to be duplicated
> like 'one' and 'one_ul' for two data types.
Hi,
Anyone looked at this patch? Does my fix looks sane?
Regards,
--
Matteo Croce
per aspera ad upstream
[PATCH] kernel/sysctl.c: fix out of bounds access in fs.file-max
fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
("sysctl: handle overflow for file-max") assigns , which is an int,
to extra1, generating the following KASAN report.
Fix this by changing 'zero' to long, which does not need to be duplicated
like 'one' and 'one_ul' for two data types.
==
BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x2f9/0x600
Read of size 8 at addr 8233dc20 by task systemd/1
CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc2-kvm+ #22
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
Call Trace:
print_address_description+0x67/0x23d
kasan_report.cold.3+0x1c/0x36
__do_proc_doulongvec_minmax+0x2f9/0x600
proc_doulongvec_minmax+0x3a/0x50
proc_sys_call_handler+0x11d/0x170
vfs_write+0xd7/0x200
ksys_write+0x93/0x110
do_syscall_64+0x57/0x140
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f67d33e8804
Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d
05 f9 5e 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54
c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
RSP: 002b:7fffd9992ed8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: RCX: 7f67d33e8804
RDX: 0015 RSI: 5586ce2607b0 RDI: 0004
RBP: 7fffd9992f30 R08: c0c0 R09:
R10: R11: 0246 R12: 0004
R13: 0015 R14: 5586ce2607c4 R15: 7fffd9992f70
The buggy address belongs to the variable:
0x8233dc20
Memory state around the buggy address:
8233db00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
8233db80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
>8233dc00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
^
8233dc80: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
8233dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max")
Signed-off-by: Matteo Croce
---
kernel/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e5da394d1ca3..3e959d67d619 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -124,7 +124,7 @@ static int sixty = 60;
static int __maybe_unused neg_one = -1;
-static int zero;
+static long zero;
static int __maybe_unused one = 1;
static int __maybe_unused two = 2;
static int __maybe_unused four = 4;
--
2.20.1
Re: fs.file-max
On Tue, May 08, 2001 at 10:03:23AM +, Federico Edelman Anaya wrote: > What can I do to test the FD limit? ... Because, the FD limit is set in > /proc/sys/fs/file-max, sample: > > echo "2048" > /proc/sys/fs/file-max > ulimit -n 8192 > > In this case ... the FD limit = 8192 :( ... when the limit should be > 2048? > > I wrote a perl script for the test ... anybody known a "C" program for > test the FD limit? Hmm, we seem to be missing this test case from the Linux Test Project. I see that dup03 exhausts all FDs and tests dup() for EMFILE. You could easily adapt that test case to a setrlimit() test case. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs.file-max
Dan: Hi ... Dan Kegel wrote: > Federico Edelman Anaya ([EMAIL PROTECTED]) wrote: > > > What can I do to test the FD limit? ... Because, the FD limit is set in > > /proc/sys/fs/file-max, sample: > > > > echo "2048" > /proc/sys/fs/file-max > > That sets the systemwide limit to 2048. Ok ... > > > > ulimit -n 8192 > > That sets the per-process limit (for this process > and its children) to 2048. > But, my perl script could open 8192 files ... I don't understand exactly work ... which is the limit of FD? file-max? > > > In this case ... the FD limit = 8192 :( ... when the limit should be > > 2048? > > No, the two limits are independant (except, obviously, that > that process will reach the systemwide fd limit before it > exhausts its per-process fd limit). > > > I wrote a perl script for the test ... anybody known a "C" program for > > test the FD limit? > > http://www.kegel.com/dkftpbench/#tuning > > - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs.file-max
Federico Edelman Anaya ([EMAIL PROTECTED]) wrote: > What can I do to test the FD limit? ... Because, the FD limit is set in > /proc/sys/fs/file-max, sample: > > echo "2048" > /proc/sys/fs/file-max That sets the systemwide limit to 2048. > ulimit -n 8192 That sets the per-process limit (for this process and its children) to 2048. > In this case ... the FD limit = 8192 :( ... when the limit should be > 2048? No, the two limits are independant (except, obviously, that that process will reach the systemwide fd limit before it exhausts its per-process fd limit). > I wrote a perl script for the test ... anybody known a "C" program for > test the FD limit? http://www.kegel.com/dkftpbench/#tuning - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fs.file-max
Hi! ... In a Linux Kernel ... What can I do to test the FD limit? ... Because, the FD limit is set in /proc/sys/fs/file-max, sample: echo "2048" > /proc/sys/fs/file-max ulimit -n 8192 In this case ... the FD limit = 8192 :( ... when the limit should be 2048? I wrote a perl script for the test ... anybody known a "C" program for test the FD limit? Thanks ...! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fs.file-max
Hi! ... In a Linux Kernel ... What can I do to test the FD limit? ... Because, the FD limit is set in /proc/sys/fs/file-max, sample: echo 2048 /proc/sys/fs/file-max ulimit -n 8192 In this case ... the FD limit = 8192 :( ... when the limit should be 2048? I wrote a perl script for the test ... anybody known a C program for test the FD limit? Thanks ...! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs.file-max
Federico Edelman Anaya ([EMAIL PROTECTED]) wrote: What can I do to test the FD limit? ... Because, the FD limit is set in /proc/sys/fs/file-max, sample: echo 2048 /proc/sys/fs/file-max That sets the systemwide limit to 2048. ulimit -n 8192 That sets the per-process limit (for this process and its children) to 2048. In this case ... the FD limit = 8192 :( ... when the limit should be 2048? No, the two limits are independant (except, obviously, that that process will reach the systemwide fd limit before it exhausts its per-process fd limit). I wrote a perl script for the test ... anybody known a C program for test the FD limit? http://www.kegel.com/dkftpbench/#tuning - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs.file-max
Dan: Hi ... Dan Kegel wrote: Federico Edelman Anaya ([EMAIL PROTECTED]) wrote: What can I do to test the FD limit? ... Because, the FD limit is set in /proc/sys/fs/file-max, sample: echo 2048 /proc/sys/fs/file-max That sets the systemwide limit to 2048. Ok ... ulimit -n 8192 That sets the per-process limit (for this process and its children) to 2048. But, my perl script could open 8192 files ... I don't understand exactly work ... which is the limit of FD? file-max? In this case ... the FD limit = 8192 :( ... when the limit should be 2048? No, the two limits are independant (except, obviously, that that process will reach the systemwide fd limit before it exhausts its per-process fd limit). I wrote a perl script for the test ... anybody known a C program for test the FD limit? http://www.kegel.com/dkftpbench/#tuning - Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs.file-max
On Tue, May 08, 2001 at 10:03:23AM +, Federico Edelman Anaya wrote: What can I do to test the FD limit? ... Because, the FD limit is set in /proc/sys/fs/file-max, sample: echo 2048 /proc/sys/fs/file-max ulimit -n 8192 In this case ... the FD limit = 8192 :( ... when the limit should be 2048? I wrote a perl script for the test ... anybody known a C program for test the FD limit? Hmm, we seem to be missing this test case from the Linux Test Project. I see that dup03 exhausts all FDs and tests dup() for EMFILE. You could easily adapt that test case to a setrlimit() test case. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sourceforge.net/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
