CVE-2021-47044

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