lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 5 Dec 2014 14:50:14 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Manfred Spraul <manfred@...orfullife.com> Cc: Andrey Ryabinin <a.ryabinin@...sung.com>, Dmitry Vyukov <dvyukov@...gle.com>, David Rientjes <rientjes@...gle.com>, Naoya Horiguchi <n-horiguchi@...jp.nec.com>, Luiz Capitulino <lcapitulino@...hat.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Nadia.Derbey@...l.net, aquini@...hat.com, davidlohr@...com, Joe Perches <joe@...ches.com>, avagin@...nvz.org, LKML <linux-kernel@...r.kernel.org>, Kostya Serebryany <kcc@...gle.com>, Dmitry Chernenkov <dmitryc@...gle.com>, Andrey Konovalov <andreyknvl@...gle.com>, Konstantin Khlebnikov <koct9i@...il.com>, kasan-dev <kasan-dev@...glegroups.com> Subject: Re: [PATCH] kernel: sysctl: use 'unsigned long' type for 'zero' variable On Thu, 04 Dec 2014 07:12:45 +0100 Manfred Spraul <manfred@...orfullife.com> wrote: > Hi Andrew, > > On 12/04/2014 12:25 AM, Andrew Morton wrote: > > On Wed, 03 Dec 2014 15:41:21 +0300 Andrey Ryabinin <a.ryabinin@...sung.com> wrote: > > > >> Use the 'unsigned long' type for 'zero' variable to fix this. > >> Changing type to 'unsigned long' shouldn't affect any other users > >> of this variable. > >> > >> Reported-by: Dmitry Vyukov <dvyukov@...gle.com> > >> Fixes: ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity") > >> Signed-off-by: Andrey Ryabinin <a.ryabinin@...sung.com> > >> --- > >> kernel/sysctl.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/kernel/sysctl.c b/kernel/sysctl.c > >> index 15f2511..45c45c9 100644 > >> --- a/kernel/sysctl.c > >> +++ b/kernel/sysctl.c > >> @@ -120,7 +120,7 @@ static int sixty = 60; > >> > >> static int __maybe_unused neg_one = -1; > >> > >> -static int zero; > >> +static unsigned long zero; > >> static int __maybe_unused one = 1; > >> static int __maybe_unused two = 2; > >> static int __maybe_unused four = 4; > > Yeah, this is ghastly. > > > > Look at > > > > { > > .procname = "numa_balancing", > > .data = NULL, /* filled in by handler */ > > .maxlen = sizeof(unsigned int), > > .mode = 0644, > > .proc_handler = sysctl_numa_balancing, > > .extra1 = &zero, > > .extra2 = &one, > > }, > > > > Now extra1 points at a long and extra2 points at an int. > > sysctl_numa_balancing() calls proc_dointvec_minmax() and I think your > > patch just broke big-endian 64-bit machines. "sched_autogroup_enabled" > > breaks as well. > What about getting rid of "extra1" and "extra2" as well and replace it > with "min" and "max"? > > I've attached an idea Looks sane. > > and change proc_dointvec_minmax() and a million other functions to take > > `union sysctl_payload *' arguments. But I haven't thought about it much. > Another idea: why do we pass "int *" instead of "int"? > > With "int", we could use > .int_min = 0; > .int_max = 1; Presumably they were originally made void* so they could point at any thing at all. But I don't recall seeing extra1 and extra2 used for anything other than bounds checking on a scalar. Problem is, these things aren't always compile-time constants. For example, pid_max_min and pid_max_max are altered at runtime. I doubt if we need to support both ints and longs in extra1/2 - longs should be OK for range-checking int values. The signed/unsigned issue needs thinking about - there's a "neg_one" in there. If we make everything "long" then we might run into signedness/range issues for sysctls which can have large unsigned values with the top bit set: 0x8000000-0xffffffff and 0x8000000000000000 - ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists