[PATCH] sched/isolation: Prevent out-of-bounds read in isolcpus= boot parameter parser

[PATCH] sched/isolation: Prevent out-of-bounds read in isolcpus= boot parameter parser

[Aaron Tomlin]

The "isolcpus=" boot parameter parser in housekeeping_isolcpus_setup()
contains an out-of-bounds memory read bug when handling unterminated
flags.

When parsing the boot parameter string, the logic expects flags to be
comma-separated. If a user passes an unrecognised or legitimate flag
at the very end of the string without a trailing comma (e.g.,
"isolcpus=unknown"), the strict strncmp() checks will fail.

The execution then falls through to a fallback for loop designed to
skip the unknown sub-parameter. This inner loop consumes characters until
it encounters either a comma or the NULL terminator ('\0'). When the loop
terminates due to hitting the end of the string, the str pointer rests
exactly on the NULL terminator.

However, immediately following this inner loop, the code unconditionally
executes str++. This advances the pointer past the end of the string
and into uninitialised memory. The outer while (isalpha(*str)) loop
subsequently evaluates this out-of-bounds memory. If the adjacent byte
happens to be alphabetical, the parser will continue reading garbage
data, potentially leading to undefined behavior or boot anomalies.

Fix this by adding a bounds check immediately before the pointer
increment. This ensures the parsing loop cleanly terminates when
reaching the end of the boot parameter string.

Fixes: 3662daf023500 ("sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters")
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
 kernel/sched/isolation.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index ef152d401fe2..9813dbeadb6d 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -355,6 +355,8 @@ static int __init housekeeping_isolcpus_setup(char *str)
 		}
 
 		pr_info("isolcpus: Skipped unknown flag %.*s\n", len, par);
+		if (!*str)
+			break;
 		str++;
 	}
 
-- 
2.51.0

Re: [PATCH] sched/isolation: Prevent out-of-bounds read in isolcpus= boot parameter parser

[Valentin Schneider]

On 23/05/26 17:02, Aaron Tomlin wrote:
> The "isolcpus=" boot parameter parser in housekeeping_isolcpus_setup()
> contains an out-of-bounds memory read bug when handling unterminated
> flags.
>
> When parsing the boot parameter string, the logic expects flags to be
> comma-separated. If a user passes an unrecognised or legitimate flag
> at the very end of the string without a trailing comma (e.g.,
> "isolcpus=unknown"), the strict strncmp() checks will fail.
>
> The execution then falls through to a fallback for loop designed to
> skip the unknown sub-parameter. This inner loop consumes characters until
> it encounters either a comma or the NULL terminator ('\0'). When the loop
> terminates due to hitting the end of the string, the str pointer rests
> exactly on the NULL terminator.
>
> However, immediately following this inner loop, the code unconditionally
> executes str++. This advances the pointer past the end of the string
> and into uninitialised memory. The outer while (isalpha(*str)) loop
> subsequently evaluates this out-of-bounds memory. If the adjacent byte
> happens to be alphabetical, the parser will continue reading garbage
> data, potentially leading to undefined behavior or boot anomalies.
>
> Fix this by adding a bounds check immediately before the pointer
> increment. This ensures the parsing loop cleanly terminates when
> reaching the end of the boot parameter string.
>
> Fixes: 3662daf023500 ("sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters")
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>

Reviewed-by: Valentin Schneider <vschneid@redhat.com>

Re: [PATCH] sched/isolation: Prevent out-of-bounds read in isolcpus= boot parameter parser

[Aaron Tomlin]

On Fri, Jun 12, 2026 at 12:11:55PM +0200, Valentin Schneider wrote:
> On 23/05/26 17:02, Aaron Tomlin wrote:
> > The "isolcpus=" boot parameter parser in housekeeping_isolcpus_setup()
> > contains an out-of-bounds memory read bug when handling unterminated
> > flags.
> >
> > When parsing the boot parameter string, the logic expects flags to be
> > comma-separated. If a user passes an unrecognised or legitimate flag
> > at the very end of the string without a trailing comma (e.g.,
> > "isolcpus=unknown"), the strict strncmp() checks will fail.
> >
> > The execution then falls through to a fallback for loop designed to
> > skip the unknown sub-parameter. This inner loop consumes characters until
> > it encounters either a comma or the NULL terminator ('\0'). When the loop
> > terminates due to hitting the end of the string, the str pointer rests
> > exactly on the NULL terminator.
> >
> > However, immediately following this inner loop, the code unconditionally
> > executes str++. This advances the pointer past the end of the string
> > and into uninitialised memory. The outer while (isalpha(*str)) loop
> > subsequently evaluates this out-of-bounds memory. If the adjacent byte
> > happens to be alphabetical, the parser will continue reading garbage
> > data, potentially leading to undefined behavior or boot anomalies.
> >
> > Fix this by adding a bounds check immediately before the pointer
> > increment. This ensures the parsing loop cleanly terminates when
> > reaching the end of the boot parameter string.
> >
> > Fixes: 3662daf023500 ("sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters")
> > Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> 
> Reviewed-by: Valentin Schneider <vschneid@redhat.com>
> 

Hi Valentin,

Thank you for your review.

As there has been no further movement on this thread since June, and given
that the forthcoming revision of the multiqueue CPU isolation series
modifies this exact parser logic in kernel/sched/isolation.c, I intend to
fold this fix directly into that series as a prerequisite patch for v16.

While ensuring a bisectable baseline, the patch will retain your
Reviewed-by: tag, the Fixes: tag, and innclude Cc to stable.

Kind regards,
-- 
Aaron Tomlin