[PATCH v2 0/3] Fixes multiple sysctl proc_handler usage error

[PATCH v2 0/3] Fixes multiple sysctl proc_handler usage error

[nicolas.bouchinet]

From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

Second iteration of the patchset to take into account Lin Feng review on
patch 1/3.

No changes for 2/3 and 3/3.

Version 1:
https://lore.kernel.org/all/20241112131357.49582-1-nicolas.bouchinet@clip-os.org/

Nicolas Bouchinet (3):
  coredump: Fixes core_pipe_limit sysctl proc_handler
  sysctl: Fix underflow value setting risk in vm_table
  tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler

 drivers/tty/tty_io.c | 2 +-
 fs/coredump.c        | 4 +++-
 kernel/sysctl.c      | 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.47.0

[PATCH v2 1/3] coredump: Fixes core_pipe_limit sysctl proc_handler

[nicolas.bouchinet]

From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

proc_dointvec converts a string to a vector of signed int, which is
stored in the unsigned int .data core_pipe_limit.
It was thus authorized to write a negative value to core_pipe_limit
sysctl which once stored in core_pipe_limit, leads to the signed int
dump_count check against core_pipe_limit never be true. The same can be
achieved with core_pipe_limit set to INT_MAX.

Any negative write or >= to INT_MAX in core_pipe_limit sysctl would
hypothetically allow a user to create very high load on the system by
running processes that produces a coredump in case the core_pattern
sysctl is configured to pipe core files to user space helper.
Memory or PID exhaustion should happen before but it anyway breaks the
core_pipe_limit semantic

This commit fixes this by changing core_pipe_limit sysctl's proc_handler
to proc_dointvec_minmax and bound checking between SYSCTL_ZERO and
SYSCTL_INT_MAX.

Fixes: a293980c2e26 ("exec: let do_coredump() limit the number of concurrent dumps to pipes")
Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
---
Changes since v1:
https://lore.kernel.org/all/20241112131357.49582-2-nicolas.bouchinet@clip-os.org/

* Remove test condition as suggested by Lin Feng.
---
 fs/coredump.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index 7f12ff6ad1d3e..c3a74dd194e69 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -1024,7 +1024,9 @@ static struct ctl_table coredump_sysctls[] = {
 		.data		= &core_pipe_limit,
 		.maxlen		= sizeof(unsigned int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= SYSCTL_ZERO,
+		.extra2		= SYSCTL_INT_MAX,
 	},
 	{
 		.procname       = "core_file_note_size_limit",
-- 
2.47.0

[PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[nicolas.bouchinet]

From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
vm_table") fixes underflow value setting risk in vm_table but misses
vdso_enabled sysctl.

vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
avoid negative value writes but the proc_handler is proc_dointvec and not
proc_dointvec_minmax and thus do not uses .extra1 and .extra2.

The following command thus works :

`# echo -1 > /proc/sys/vm/vdso_enabled`

This patch properly sets the proc_handler to proc_dointvec_minmax.

Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
---
 kernel/sysctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 79e6cb1d5c48f..37b1c1a760985 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
 		.maxlen		= sizeof(vdso_enabled),
 #endif
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
 		.extra1		= SYSCTL_ZERO,
 	},
 #endif
-- 
2.47.0

Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Joel Granados]

On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> 
> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
> vm_table") fixes underflow value setting risk in vm_table but misses
> vdso_enabled sysctl.
> 
> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
> avoid negative value writes but the proc_handler is proc_dointvec and not
> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
> 
> The following command thus works :
> 
> `# echo -1 > /proc/sys/vm/vdso_enabled`
It would be interesting to know what happens when you do a
# echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled

This is the reasons why I'm interested in such a test:

1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
   overflow check where they will return -EINVAL if what is given by the user is
   greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
   or false depending on the architecture where we are running.

2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
   that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
   would not be the case.

So my question is: What is the expected range for this value? Because you might
not be getting the whole range in the cases where int is 32 bit and long is 64
bit.

> 
> This patch properly sets the proc_handler to proc_dointvec_minmax.
> 
> Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> ---
>  kernel/sysctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 79e6cb1d5c48f..37b1c1a760985 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
>  		.maxlen		= sizeof(vdso_enabled),
>  #endif
>  		.mode		= 0644,
> -		.proc_handler	= proc_dointvec,
> +		.proc_handler	= proc_dointvec_minmax,
>  		.extra1		= SYSCTL_ZERO,
Any reason why extra2 is not defined. I know that it was not defined before, but
this does not mean that it will not have an upper limit. The way that I read the
situation is that this will be bounded by the overflow check done in
proc_dointvec and will have an upper limit of INT_MAX.

Please correct me if I have read the situation incorrectly.

Best

-- 

Joel Granados

Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Nicolas Bouchinet]

Hi Joel,


Thank's for your reply.

I apologize for the reply delay, I wasn't available late weeks.

On 11/20/24 1:53 PM, Joel Granados wrote:
> On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
>> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>>
>> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
>> vm_table") fixes underflow value setting risk in vm_table but misses
>> vdso_enabled sysctl.
>>
>> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
>> avoid negative value writes but the proc_handler is proc_dointvec and not
>> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
>>
>> The following command thus works :
>>
>> `# echo -1 > /proc/sys/vm/vdso_enabled`
> It would be interesting to know what happens when you do a
> # echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled

Great question, I'll check that.

>
> This is the reasons why I'm interested in such a test:
>
> 1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
>     overflow check where they will return -EINVAL if what is given by the user is
>     greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
>     or false depending on the architecture where we are running.

Indeed, I'll run tests to avouch behaviors of proc handlers bound checks 
with
different architectures.

>
> 2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
>     that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
>     would not be the case.
Yep, it is. As I've tried to explain in the cover letter
(https://lore.kernel.org/all/20241112131357.49582-1-nicolas.bouchinet@clip-os.org/),
there are numerous places where sysctl data type differs from the proc 
handler
return type.

AFAIK, for proc_dointvec there is more than 10 different sysctl where it
happens. The three I've patched represents three common mistakes using
proc_handlers.

>
> So my question is: What is the expected range for this value? Because you might
> not be getting the whole range in the cases where int is 32 bit and long is 64
> bit.
>
>> This patch properly sets the proc_handler to proc_dointvec_minmax.
>>
>> Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
>> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>> ---
>>   kernel/sysctl.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index 79e6cb1d5c48f..37b1c1a760985 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
>>   		.maxlen		= sizeof(vdso_enabled),
>>   #endif
>>   		.mode		= 0644,
>> -		.proc_handler	= proc_dointvec,
>> +		.proc_handler	= proc_dointvec_minmax,
>>   		.extra1		= SYSCTL_ZERO,
> Any reason why extra2 is not defined. I know that it was not defined before, but
> this does not mean that it will not have an upper limit. The way that I read the
> situation is that this will be bounded by the overflow check done in
> proc_dointvec and will have an upper limit of INT_MAX.

Yes, it is bounded by the overflow checks done in proc_dointvec, I've not
changed the current sysctl behavior but we should bound it between 0
and 1 since it seems vdso compat is not supported anymore since
Commit b0b49f2673f011cad ("x86, vdso: Remove compat vdso support").

This is the behavior of vdso32_enabled exposed under the abi sysctl
node.

>
> Please correct me if I have read the situation incorrectly.
You perfectly understood the problematic of it, thanks a lot for your 
review.

I'll reply to above questions after I've run more tests.

I saw GKH already merged the third commit of this patchset and 
backported it to stable branches.
Should I evict it from future version of this patchset ?

Thanks,

Nicolas

>
> Best
>

Re: Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Joel Granados]

On Tue, Dec 10, 2024 at 03:58:41PM +0100, Nicolas Bouchinet wrote:
> Hi Joel,
> 
> 
> Thank's for your reply.
> 
> I apologize for the reply delay, I wasn't available late weeks.
> 
> On 11/20/24 1:53 PM, Joel Granados wrote:
> > On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
> >> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> >>
> >> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
> >> vm_table") fixes underflow value setting risk in vm_table but misses
> >> vdso_enabled sysctl.
> >>
> >> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
> >> avoid negative value writes but the proc_handler is proc_dointvec and not
> >> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
> >>
> >> The following command thus works :
> >>
> >> `# echo -1 > /proc/sys/vm/vdso_enabled`
> > It would be interesting to know what happens when you do a
> > # echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled
> 
> Great question, I'll check that.
> 
> >
> > This is the reasons why I'm interested in such a test:
> >
> > 1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
> >     overflow check where they will return -EINVAL if what is given by the user is
> >     greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
> >     or false depending on the architecture where we are running.
> 
> Indeed, I'll run tests to avouch behaviors of proc handlers bound checks 
> with
> different architectures.
> 
> >
> > 2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
> >     that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
> >     would not be the case.
> Yep, it is. As I've tried to explain in the cover letter
> (https://lore.kernel.org/all/20241112131357.49582-1-nicolas.bouchinet@clip-os.org/),
> there are numerous places where sysctl data type differs from the proc 
> handler
> return type.
> 
> AFAIK, for proc_dointvec there is more than 10 different sysctl where it
> happens. The three I've patched represents three common mistakes using
> proc_handlers.
It would be useful to analyze the others. Do you have more outstanding
patches for these?

> 
> >
> > So my question is: What is the expected range for this value? Because you might
> > not be getting the whole range in the cases where int is 32 bit and long is 64
> > bit.
> >
> >> This patch properly sets the proc_handler to proc_dointvec_minmax.
> >>
> >> Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
> >> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> >> ---
> >>   kernel/sysctl.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> >> index 79e6cb1d5c48f..37b1c1a760985 100644
> >> --- a/kernel/sysctl.c
> >> +++ b/kernel/sysctl.c
> >> @@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
> >>   		.maxlen		= sizeof(vdso_enabled),
> >>   #endif
> >>   		.mode		= 0644,
> >> -		.proc_handler	= proc_dointvec,
> >> +		.proc_handler	= proc_dointvec_minmax,
> >>   		.extra1		= SYSCTL_ZERO,
> > Any reason why extra2 is not defined. I know that it was not defined before, but
> > this does not mean that it will not have an upper limit. The way that I read the
> > situation is that this will be bounded by the overflow check done in
> > proc_dointvec and will have an upper limit of INT_MAX.
> 
> Yes, it is bounded by the overflow checks done in proc_dointvec, I've not
> changed the current sysctl behavior but we should bound it between 0
> and 1 since it seems vdso compat is not supported anymore since
> Commit b0b49f2673f011cad ("x86, vdso: Remove compat vdso support").
I think you have already done this in your V3

> 
> This is the behavior of vdso32_enabled exposed under the abi sysctl
> node.
> 
> >
> > Please correct me if I have read the situation incorrectly.
> You perfectly understood the problematic of it, thanks a lot for your 
> review.
> 
> I'll reply to above questions after I've run more tests.
> 
> I saw GKH already merged the third commit of this patchset and 
> backported it to stable branches.
> Should I evict it from future version of this patchset ?
Yes. You should remove what has already been merged into main
line. thx.

Best 

-- 

Joel Granados

Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Nicolas Bouchinet]

On 12/18/24 14:21, Joel Granados wrote:
> On Tue, Dec 10, 2024 at 03:58:41PM +0100, Nicolas Bouchinet wrote:
>> Hi Joel,
>>
>>
>> Thank's for your reply.
>>
>> I apologize for the reply delay, I wasn't available late weeks.
>>
>> On 11/20/24 1:53 PM, Joel Granados wrote:
>>> On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
>>>> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>>>>
>>>> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
>>>> vm_table") fixes underflow value setting risk in vm_table but misses
>>>> vdso_enabled sysctl.
>>>>
>>>> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
>>>> avoid negative value writes but the proc_handler is proc_dointvec and not
>>>> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
>>>>
>>>> The following command thus works :
>>>>
>>>> `# echo -1 > /proc/sys/vm/vdso_enabled`
>>> It would be interesting to know what happens when you do a
>>> # echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled
>> Great question, I'll check that.
>>
>>> This is the reasons why I'm interested in such a test:
>>>
>>> 1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
>>>      overflow check where they will return -EINVAL if what is given by the user is
>>>      greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
>>>      or false depending on the architecture where we are running.
>> Indeed, I'll run tests to avouch behaviors of proc handlers bound checks
>> with
>> different architectures.
>>
>>> 2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
>>>      that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
>>>      would not be the case.
>> Yep, it is. As I've tried to explain in the cover letter
>> (https://lore.kernel.org/all/20241112131357.49582-1-nicolas.bouchinet@clip-os.org/),
>> there are numerous places where sysctl data type differs from the proc
>> handler
>> return type.
>>
>> AFAIK, for proc_dointvec there is more than 10 different sysctl where it
>> happens. The three I've patched represents three common mistakes using
>> proc_handlers.
> It would be useful to analyze the others. Do you have more outstanding
> patches for these?

I've started to analyze them more in depth it this monday, will send a 
patchset when
it seems ok.
I'm focusing on proc_dointvec for now.

>
>>> So my question is: What is the expected range for this value? Because you might
>>> not be getting the whole range in the cases where int is 32 bit and long is 64
>>> bit.
>>>
>>>> This patch properly sets the proc_handler to proc_dointvec_minmax.
>>>>
>>>> Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
>>>> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>>>> ---
>>>>    kernel/sysctl.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>>> index 79e6cb1d5c48f..37b1c1a760985 100644
>>>> --- a/kernel/sysctl.c
>>>> +++ b/kernel/sysctl.c
>>>> @@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
>>>>    		.maxlen		= sizeof(vdso_enabled),
>>>>    #endif
>>>>    		.mode		= 0644,
>>>> -		.proc_handler	= proc_dointvec,
>>>> +		.proc_handler	= proc_dointvec_minmax,
>>>>    		.extra1		= SYSCTL_ZERO,
>>> Any reason why extra2 is not defined. I know that it was not defined before, but
>>> this does not mean that it will not have an upper limit. The way that I read the
>>> situation is that this will be bounded by the overflow check done in
>>> proc_dointvec and will have an upper limit of INT_MAX.
>> Yes, it is bounded by the overflow checks done in proc_dointvec, I've not
>> changed the current sysctl behavior but we should bound it between 0
>> and 1 since it seems vdso compat is not supported anymore since
>> Commit b0b49f2673f011cad ("x86, vdso: Remove compat vdso support").
> I think you have already done this in your V3
>
>> This is the behavior of vdso32_enabled exposed under the abi sysctl
>> node.
>>
>>> Please correct me if I have read the situation incorrectly.
>> You perfectly understood the problematic of it, thanks a lot for your
>> review.
>>
>> I'll reply to above questions after I've run more tests.
>>
>> I saw GKH already merged the third commit of this patchset and
>> backported it to stable branches.
>> Should I evict it from future version of this patchset ?
> Yes. You should remove what has already been merged into main
> line. thx.
>
> Best
>

Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Nicolas Bouchinet]

Hi Joel,

I've pushed patchset version 3 :
https://lore.kernel.org/all/20241217132908.38096-1-nicolas.bouchinet@clip-os.org/.

On 11/20/24 13:53, Joel Granados wrote:
> On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
>> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>>
>> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
>> vm_table") fixes underflow value setting risk in vm_table but misses
>> vdso_enabled sysctl.
>>
>> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
>> avoid negative value writes but the proc_handler is proc_dointvec and not
>> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
>>
>> The following command thus works :
>>
>> `# echo -1 > /proc/sys/vm/vdso_enabled`
> It would be interesting to know what happens when you do a
> # echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled
>
> This is the reasons why I'm interested in such a test:
>
> 1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
>     overflow check where they will return -EINVAL if what is given by the user is
>     greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
>     or false depending on the architecture where we are running.
>
> 2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
>     that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
>     would not be the case.
 From my observations, vdso_enabled is a unsigned int. If one wants to
convert to an unsigned long, proc_doulongvec_minmax should be used
instead.

IMHO, the main issues are that .data variable type can differ from the 
return
type of .proc_handler function. This can lead to undefined behaviors and
eventually vulnerabilities.

.extra1 and .extra2 can also be used with proc_handlers that do not uses 
them.
I think sysctl_check_table() could be enhanced to control this behavior.

>
> So my question is: What is the expected range for this value? Because you might
> not be getting the whole range in the cases where int is 32 bit and long is 64
> bit.
If proc_dointvec or its derivative is used, as you said, range is bounded
by checks in do_proc_dointvec_conv ((unsigned long) INT_MAX).

INT_MAX being based on the max value of an int (((int)(~0U >> 1))),
do_proc_dointvec_conv behavior is thus architecture dependent.
>
>> This patch properly sets the proc_handler to proc_dointvec_minmax.
>>
>> Fixes: 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in vm_table")
>> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>> ---
>>   kernel/sysctl.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index 79e6cb1d5c48f..37b1c1a760985 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -2194,7 +2194,7 @@ static struct ctl_table vm_table[] = {
>>   		.maxlen		= sizeof(vdso_enabled),
>>   #endif
>>   		.mode		= 0644,
>> -		.proc_handler	= proc_dointvec,
>> +		.proc_handler	= proc_dointvec_minmax,
>>   		.extra1		= SYSCTL_ZERO,
> Any reason why extra2 is not defined. I know that it was not defined before, but
> this does not mean that it will not have an upper limit. The way that I read the
> situation is that this will be bounded by the overflow check done in
> proc_dointvec and will have an upper limit of INT_MAX.

I've added an extra2 parameter to restrict vdso_enabled between 0 and 1 
in patchset v3.
https://lore.kernel.org/all/20241217132908.38096-3-nicolas.bouchinet@clip-os.org/

>
> Please correct me if I have read the situation incorrectly.
>
> Best
>
Thanks again for your review,

Best regards,

Nicolas

Re: Re: [PATCH v2 2/3] sysctl: Fix underflow value setting risk in vm_table

[Joel Granados]

On Tue, Dec 17, 2024 at 02:57:51PM +0100, Nicolas Bouchinet wrote:
> Hi Joel,
> 
> I've pushed patchset version 3 :
> https://lore.kernel.org/all/20241217132908.38096-1-nicolas.bouchinet@clip-os.org/.
> 
> On 11/20/24 13:53, Joel Granados wrote:
> > On Thu, Nov 14, 2024 at 05:25:51PM +0100, nicolas.bouchinet@clip-os.org wrote:
> >> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> >>
> >> Commit 3b3376f222e3 ("sysctl.c: fix underflow value setting risk in
> >> vm_table") fixes underflow value setting risk in vm_table but misses
> >> vdso_enabled sysctl.
> >>
> >> vdso_enabled sysctl is initialized with .extra1 value as SYSCTL_ZERO to
> >> avoid negative value writes but the proc_handler is proc_dointvec and not
> >> proc_dointvec_minmax and thus do not uses .extra1 and .extra2.
> >>
> >> The following command thus works :
> >>
> >> `# echo -1 > /proc/sys/vm/vdso_enabled`
> > It would be interesting to know what happens when you do a
> > # echo (INT_MAX + 1) > /proc/sys/vm/vdso_enabled
> >
> > This is the reasons why I'm interested in such a test:
> >
> > 1. Both proc_dointvec and proc_dointvec_minmax (calls proc_dointvec) have a
> >     overflow check where they will return -EINVAL if what is given by the user is
> >     greater than (unsiged long)INT_MAX; this will evaluate can evaluate to true
> >     or false depending on the architecture where we are running.
> >
> > 2. I noticed that vdso_enabled is an unsigned long. And so the expectation is
> >     that the range is 0 to ULONG_MAX, which in some cases (depending on the arch)
> >     would not be the case.
>  From my observations, vdso_enabled is a unsigned int. If one wants to
> convert to an unsigned long, proc_doulongvec_minmax should be used
> instead.
Yep, 100% agree, I miss-read and commented incorrectly. Just ignore my
previous comment; I don't know what I was smoking...

> 
> IMHO, the main issues are that .data variable type can differ from the
> return type of .proc_handler function. This can lead to undefined
> behaviors and eventually vulnerabilities.
I totally agree that it can lead to unexpected behavior. Would have to
look at a specific case to see if it is really "undefined". 

> 
> .extra1 and .extra2 can also be used with proc_handlers that do not
> uses them.
In this case they are just silently ignored. Leading the developer to
believe that they are range checked, when they are really not.

> I think sysctl_check_table() could be enhanced to control
> this behavior.
This might be the case. I can review a proposal if you send it out.

Best

-- 

Joel Granados

[PATCH v2 3/3] tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler

[nicolas.bouchinet]

From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

Commit 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of
ldiscs") introduces the tty_ldisc_autoload sysctl with the wrong
proc_handler. .extra1 and .extra2 parameters are set to avoid other values
thant SYSCTL_ZERO or SYSCTL_ONE to be set but proc_dointvec do not uses
them.

This commit fixes this by using proc_dointvec_minmax instead of
proc_dointvec.

Fixes: 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs")
Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
---
 drivers/tty/tty_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 407b0d87b7c10..f211154367420 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3631,7 +3631,7 @@ static struct ctl_table tty_table[] = {
 		.data		= &tty_ldisc_autoload,
 		.maxlen		= sizeof(tty_ldisc_autoload),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
 		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_ONE,
 	},
-- 
2.47.0