Description

In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine.

Metrics

 

CVSS Version 4.0 CVSS Version 3.x CVSS Version 2.0

NVD enrichment efforts reference publicly available information to associate vector strings. CVSS information contributed by other sources is also displayed.

CVSS 4.0 Severity and Vector Strings:

NIST: NVD

N/A

NVD assessment not yet provided.

CVSS 3.x Severity and Vector Strings:

NIST: NVD

Base Score:  N/A

NVD assessment not yet provided.

ADP:  CISA-ADP

Base Score:  7.7 HIGH

Vector:  CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

CVSS 2.0 Severity and Vector Strings:

NIST: NVD

Base Score: N/A

NVD assessment not yet provided.

https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54

https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5

https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f

https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774

CISA-ADP AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

CISA-ADP CWE-125

In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Fix shift-out-of-bounds in load_balance()

Syzbot reported a handful of occurrences where an sd->nr_balance_failed can
grow to much higher values than one would expect.

A successful load_balance() resets it to 0; a failed one increments
it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an
active balance, which will either set it to sd->cache_nice_tries+1 or reset
it to 0. However, in case the to-b

Linux https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54 [No types assigned]

Linux https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5 [No types assigned]

Linux https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f [No types assigned]

Linux https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774 [No types assigned]