CVE-2022-49961
published 2025-06-18CVE-2022-49961: In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be…
PriorityP431high7.1CVSS 3.1
AVLACLPRLUINSUCHINAH
EPSS
0.22%
12.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.
To show a concrete example of the problem:
0000000000000000 :
0: r2 = *(u32 *)(r1 + 80)
1: r1 = *(u32 *)(r1 + 76)
2: r3 = r1
3: r3 += 4
4: if r3 > r2 goto +18
5: w2 = 0
6: *(u32 *)(r1 + 0) = r2
7: r1 = *(u32 *)(r1 + 0)
8: r2 = 1
9: if w1 == 0 goto +1
10: r2 = -1
0000000000000058 :
11: r1 = 0 ll
13: r3 = 0
14: call bpf_ringbuf_reserve
15: if r0 == 0 goto +7
16: r1 = r0
17: r1 += 16777215
18: w2 = 0
19: *(u8 *)(r1 + 0) = r2
20: r1 = r0
21: r2 = 0
22: call bpf_ringbuf_submit
00000000000000b8 :
23: w0 = 0
24: exit
For the first case, the single line execution's exploration will prune
the search at insn 14 for the branch insn 9's second leg as it will be
verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will
always be 0 so at runtime we don't get error for being greater than
UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just
sees reg->precise as false for both r2 registers in both states, hence
considers them equal for purposes of states_equal.
If we propagated precise markers using the backtracking support, we
would use the precise marking to then ensure that old r2 (UINT_MAX) was
within the new r2 (1) and this would never be true, so the v
Affected
38 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.19.11-1 (bookworm) | linux 5.19.11-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < 987b4c465ba28c662ca857be6c20fd2d96bc55f0 | 987b4c465ba28c662ca857be6c20fd2d96bc55f0 |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < 2459615a8d7f44ac81f0965bc094e55ccb254717 | 2459615a8d7f44ac81f0965bc094e55ccb254717 |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < 2fc31465c5373b5ca4edf2e5238558cb62902311 | 2fc31465c5373b5ca4edf2e5238558cb62902311 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 5.8 < 5.19.8 | 5.19.8 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
| ubuntu | linux | — | — |
| ubuntu | linux-aws | — | — |
| ubuntu | linux-aws-5.15 | — | — |
| ubuntu | linux-aws-fips | — | — |
| ubuntu | linux-azure-5.15 | — | — |
| ubuntu | linux-azure-fde | — | — |
| ubuntu | linux-azure-fde-5.15 | — | — |
| ubuntu | linux-fips | — | — |
| ubuntu | linux-gcp | — | — |
| ubuntu | linux-gcp-fips | — | — |
| ubuntu | linux-gke | — | — |
| ubuntu | linux-gkeop | — | — |
CVSS provenance
nvdv3.17.1HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
osv7.1HIGH
vendor_debian7.1HIGH
vendor_redhat7.1HIGH
vendor_ubuntu7.1HIGH
vendor_msrc6.0MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2026-07-28·CVSS 7.1
CVE-2024-36898 [HIGH] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A local
Ubuntu
Linux kernel (Azure CVM) vulnerabilities
vendor_ubuntu·2026-07-24·CVSS 7.1
CVE-2024-36898 [HIGH] Linux kernel (Azure CVM) vulnerabilities
Title: Linux kernel (Azure CVM) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cac
Ubuntu
Linux kernel (IBM) vulnerabilities
vendor_ubuntu·2026-07-23·CVSS 7.1
CVE-2026-46187 [HIGH] Linux kernel (IBM) vulnerabilities
Title: Linux kernel (IBM) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2026-07-23·CVSS 7.1
CVE-2026-46187 [HIGH] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A local
Ubuntu
Linux kernel (NVIDIA Tegra) vulnerabilities
vendor_ubuntu·2026-07-23·CVSS 7.1
CVE-2026-46187 [HIGH] Linux kernel (NVIDIA Tegra) vulnerabilities
Title: Linux kernel (NVIDIA Tegra) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2026-07-21·CVSS 7.1
CVE-2024-36898 [HIGH] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A local
Ubuntu
Linux kernel (NVIDIA Tegra) vulnerabilities
vendor_ubuntu·2026-07-21·CVSS 7.1
CVE-2024-36898 [HIGH] Linux kernel (NVIDIA Tegra) vulnerabilities
Title: Linux kernel (NVIDIA Tegra) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Maxim Suhanov discovered that the NTFS file system implementation in the
Linux kernel did not properly validate file name length in certain
situations, leading to an out-of-bounds read. An attacker could use this to
construct a malicious NTFS image that, when mounted and operated on, could
expose sensitive information (kernel memory). (CVE-2023-45896)
It was discovered that some AMD processors did not properly clear data in
the floating point divider unit during speculative execution. A local
attacker could use this to expose sensitive information. (CVE-2025-54505)
It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation
Red Hat
kernel: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
vendor_redhat·2025-06-18·CVSS 7.1
CVE-2022-49961 [HIGH] kernel: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
kernel: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do acce
Microsoft
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
vendor_msrc·2025-06-10·CVSS 6.0
CVE-2022-49961 [HIGH] CWE-125 bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Debian
CVE-2022-49961: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Do mar...
vendor_debian·2022·CVSS 7.1
CVE-2022-49961 [HIGH] CVE-2022-49961: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Do mar...
In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored s
OSV
CVE-2022-49961: In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers ne
osv·2025-06-18·CVSS 7.1
CVE-2022-49961 [HIGH] CVE-2022-49961: In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers ne
In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored s
GHSA
GHSA-34r5-4vr6-q5h6: In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers
ghsa_unreviewed·2025-06-18
CVE-2022-49961 [HIGH] CWE-125 GHSA-34r5-4vr6-q5h6: In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored
No detection rules found.
No public exploits indexed.
2025-06-18
Published