linux-cve-announce - CVE-2021-47396: mac80211-hwsim: fix late beacon hrtimer handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2024052148-CVE-2021-47396-42fa@gregkh>
Date: Tue, 21 May 2024 17:04:13 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2021-47396: mac80211-hwsim: fix late beacon hrtimer handling

Description
===========

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

mac80211-hwsim: fix late beacon hrtimer handling

Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx
that our handling of the hrtimer here is wrong: If the timer fires
late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)
then it tries to actually rearm the timer at the next deadline,
which might be in the past already:

 1          2          3          N          N+1
 |          |          |   ...    |          |

 ^ intended to fire here (1)
            ^ next deadline here (2)
                                      ^ actually fired here

The next time it fires, it's later, but will still try to schedule
for the next deadline (now 3), etc. until it catches up with N,
but that might take a long time, causing stalls etc.

Now, all of this is simulation, so we just have to fix it, but
note that the behaviour is wrong even per spec, since there's no
value then in sending all those beacons unaligned - they should be
aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a
bit (or a lot) late, then just resume at that point.

Therefore, change the code to use hrtimer_forward_now() which will
ensure that the next firing of the timer would be at N+1 (in the
picture), i.e. the next interval point after the current time.

The Linux kernel CVE team has assigned CVE-2021-47396 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 3.9 with commit 01e59e467ecf and fixed in 5.4.151 with commit 9bee85de2c81
	Issue introduced in 3.9 with commit 01e59e467ecf and fixed in 5.10.71 with commit 2c204cf594df
	Issue introduced in 3.9 with commit 01e59e467ecf and fixed in 5.14.10 with commit ed2adf69e298
	Issue introduced in 3.9 with commit 01e59e467ecf and fixed in 5.15 with commit 313bbd1990b6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2021-47396
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	drivers/net/wireless/mac80211_hwsim.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05
	https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7
	https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed
	https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572