Linux: Out-of-bounds Read
CVE-2022-49961 is a high-severity out-of-bounds read vulnerability in Linux, with a CVSS 3.1 base score of 7.1 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 65efb481eb4572fce0f20aa6c13e880816b81579, 987b4c465ba28c662ca857be6c20fd2d96bc55f0, 2459615a8d7f44ac81f0965bc094e55ccb254717 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.29% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 65efb481eb4572fce0f20aa6c13e880816b81579 or 987b4c465ba28c662ca857be6c20fd2d96bc55f0 or 2459615a8d7f44ac81f0965bc094e55ccb254717 or 2fc31465c5373b5ca4edf2e5238558cb62902311, whichever matches your release line, or a later version.
- Update Linux Kernel to 5.19.8 or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 457f44363a8894135c85b7a9afd2bd8196db24ab up to, but not including, 65efb481eb4572fce0f20aa6c13e880816b81579; 457f44363a8894135c85b7a9afd2bd8196db24ab up to, but not including, 987b4c465ba28c662ca857be6c20fd2d96bc55f0; 457f44363a8894135c85b7a9afd2bd8196db24ab up to, but not including, 2459615a8d7f44ac81f0965bc094e55ccb254717; 457f44363a8894135c85b7a9afd2bd8196db24ab up to, but not including, 2fc31465c5373b5ca4edf2e5238558cb62902311; 5.8 | 65efb481eb4572fce0f20aa6c13e880816b81579, 987b4c465ba28c662ca857be6c20fd2d96bc55f0, 2459615a8d7f44ac81f0965bc094e55ccb254717, 2fc31465c5373b5ca4edf2e5238558cb62902311 |
| Linux | Linux Kernel | 5.8 up to, but not including, 5.19.8; 6.0 | 5.19.8 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- NoneNothing can be modified.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H. Scored by NVD.
Official description
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 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 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 <LBB5_5>: 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 verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
How developers prevent this class of flaw
- Use a language that provides appropriate memory abstractions.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
Recent Out-of-bounds Read vulnerabilities
- 7.5 High severity
- 7.1 High severity
- 7.1 High severity
- 7.1 High severity
- 7.1 High severity
- 7.1 High severity
Spotted an error? Tell us.