Linux: Integer Overflow or Wraparound
CVE-2026-46325 is a critical-severity integer overflow or wraparound vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions e327021bd73b134c18167e2cd2a52eb5597fcba6, 2a585a08a43c568ed6e9f27a97fd3d95106b9e68, 409c2c5508f3d30627bea576f8676de523cb906e 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.45% chance of exploitation within 30 days, which is low compared with other CVEs.
Critical severity: a successful attack would have severe impact.
What to do
- Update Linux to e327021bd73b134c18167e2cd2a52eb5597fcba6 or 2a585a08a43c568ed6e9f27a97fd3d95106b9e68 or 409c2c5508f3d30627bea576f8676de523cb906e or 836f6c13c9674027793f720be3f15ecd2b90b6ca, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.18.14 or 6.19.4, whichever matches your release line, or a later version.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 592627ccbdff0ec6fff00fc761142a76db750dd4 up to, but not including, e327021bd73b134c18167e2cd2a52eb5597fcba6; 592627ccbdff0ec6fff00fc761142a76db750dd4 up to, but not including, 2a585a08a43c568ed6e9f27a97fd3d95106b9e68; 592627ccbdff0ec6fff00fc761142a76db750dd4 up to, but not including, 409c2c5508f3d30627bea576f8676de523cb906e; 592627ccbdff0ec6fff00fc761142a76db750dd4 up to, but not including, 836f6c13c9674027793f720be3f15ecd2b90b6ca; 592627ccbdff0ec6fff00fc761142a76db750dd4 up to, but not including, 12985e5915a0b8354796efadaaeb201eed115377; 0e443760b8b7b1e6723f4408afa056b2bc4fea12; 6.2.3 up to, but not including, 6.3; 6.3 | e327021bd73b134c18167e2cd2a52eb5597fcba6, 2a585a08a43c568ed6e9f27a97fd3d95106b9e68, 409c2c5508f3d30627bea576f8676de523cb906e, 836f6c13c9674027793f720be3f15ecd2b90b6ca, 12985e5915a0b8354796efadaaeb201eed115377, 6.3 |
| Linux | Linux Kernel | 6.2.3 up to, but not including, 6.18.14; 6.19 up to, but not including, 6.19.4 | 6.18.14, 6.19.4 |
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
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- 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
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official description
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Integer Overflow or Wraparound
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
How developers prevent this class of flaw
- Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. If possible, choose a language or compiler that performs automatic bounds checking.
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Use libraries or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
More Integer Overflow or Wraparound vulnerabilities (CWE-190)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
Recent Integer Overflow or Wraparound vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 8.8 High severity
- 8.3 High severity
- 8.3 High severity
- 7.5 High severity
Spotted an error? Tell us.