CVE-2026-72105: Linux kernel · dm-log: fix a bitset_size overflow on 32bit machines
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in e0b0163a65758ec3a2361ae1cea407898c27f21e : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in e0b0163a65758ec3a2361ae1cea407898c27f21e, d05e0edfecf5260e6dddd28b2f0cce02bfc6ed7a, cdc4ddf9db2cb79f4ab86b1a509b7ac21b0b6cf5 +12
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 15 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.
References
- git.kernel.org/stable/c/cdc4ddf9db2cb79f4ab86b1a509b7ac21b0b6cf5 (opens in a new tab)
- git.kernel.org/stable/c/4b0de5a3ac1fd42acb0dc1f80ac5747e3287d723 (opens in a new tab)
- git.kernel.org/stable/c/567602fa72d57169365cbc589e0b8c3be900636d (opens in a new tab)
- git.kernel.org/stable/c/d05e0edfecf5260e6dddd28b2f0cce02bfc6ed7a (opens in a new tab)
- git.kernel.org/stable/c/1c3412b584e1fb6c665ff33ba7259253bc0082cb (opens in a new tab)
- git.kernel.org/stable/c/e0b0163a65758ec3a2361ae1cea407898c27f21e (opens in a new tab)
- git.kernel.org/stable/c/79feb87ab2396d49b9b65e4bb815d33cc71cba47 (opens in a new tab)
- git.kernel.org/stable/c/9743132a41f4d9d0e54c5f2adcb821b04796bab1 (opens in a new tab)