DEBIAN-CVE-2022-50279

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2022-50279
Import Source
https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-50279.json
JSON Data
https://api.test.osv.dev/v1/vulns/DEBIAN-CVE-2022-50279
Upstream
Published
2025-09-15T15:15:38Z
Modified
2025-09-19T07:33:07.419919Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Fix global-out-of-bounds bug in rtl8812aephysettxpowerlimit() There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812aeeqnbyte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasanreport+0xbb/0x1c0 _rtl8812aeeqnbyte.part.0+0x3d/0x84 [rtl8821ae] rtl8821aephybbconfig.cold+0x346/0x641 [rtl8821ae] rtl8821aehwinit+0x1f5e/0x79b0 [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of "pratesection" in rtl8812aephysettxpowerlimit() is wrong. The _rtl8812aeeqnbyte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the rtl8812aephysettxpowerlimit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "pratesection" dose not obey such order requirement, therefore when "pratesection" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812aeeqnbyte(). As mentioned above, the rtl8812aeeqnbyte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing rtl8812aeeqnbyte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "pratesection", this may cause the value of "ratesection" to not be from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit.

References

Affected packages

Debian:11 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.178-1

Affected versions

5.*

5.10.46-4
5.10.46-5
5.10.70-1~bpo10+1
5.10.70-1
5.10.84-1
5.10.92-1~bpo10+1
5.10.92-1
5.10.92-2
5.10.103-1~bpo10+1
5.10.103-1
5.10.106-1
5.10.113-1
5.10.120-1~bpo10+1
5.10.120-1
5.10.127-1
5.10.127-2~bpo10+1
5.10.127-2
5.10.136-1
5.10.140-1
5.10.148-1
5.10.149-1
5.10.149-2
5.10.158-1
5.10.158-2
5.10.162-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.20-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.20-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.20-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}