CVE-2021-47396

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211-hwsim: fix late beacon hrtimer handling<br /> <br /> Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx<br /> that our handling of the hrtimer here is wrong: If the timer fires<br /> late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)<br /> then it tries to actually rearm the timer at the next deadline,<br /> which might be in the past already:<br /> <br /> 1 2 3 N N+1<br /> | | | ... | |<br /> <br /> ^ intended to fire here (1)<br /> ^ next deadline here (2)<br /> ^ actually fired here<br /> <br /> The next time it fires, it&amp;#39;s later, but will still try to schedule<br /> for the next deadline (now 3), etc. until it catches up with N,<br /> but that might take a long time, causing stalls etc.<br /> <br /> Now, all of this is simulation, so we just have to fix it, but<br /> note that the behaviour is wrong even per spec, since there&amp;#39;s no<br /> value then in sending all those beacons unaligned - they should be<br /> aligned to the TBTT (1, 2, 3, ... in the picture), and if we&amp;#39;re a<br /> bit (or a lot) late, then just resume at that point.<br /> <br /> Therefore, change the code to use hrtimer_forward_now() which will<br /> ensure that the next firing of the timer would be at N+1 (in the<br /> picture), i.e. the next interval point after the current time.