CVE-2026-53059
Last modified
CVE-2026-53059 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to region_count overflow The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count.. EPSS estimates a 0.14% chance of exploitation in the next 30 days.
Description
In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to region_count overflow The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count.
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness Enumeration
Affected Software
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux Kernel | >= 2.6.12.1, < 5.10.258 |
| Linux | Linux Kernel | >= 5.11, < 5.15.209 |
| Linux | Linux Kernel | >= 5.16, < 6.1.175 |
| Linux | Linux Kernel | >= 6.2, < 6.6.141 |
| Linux | Linux Kernel | >= 6.7, < 6.12.91 |
| Linux | Linux Kernel | >= 6.13, < 6.18.33 |
| Linux | Linux Kernel | >= 6.19, < 7.0.10 |
| Linux | Linux Kernel | 2.6.12 |
References
- https://access.redhat.com/security/cve/CVE-2026-53059Third Party Advisory
- https://bugzilla.redhat.com/show_bug.cgi?id=2492277Third Party Advisory
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53059.jsonThird Party Advisory
Timeline
- Published
- Last Modified
- Status
- Modified
Frequently Asked Questions
What is CVE-2026-53059?
How severe is CVE-2026-53059?
How do I fix CVE-2026-53059?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-53053In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-53054In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-53055In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-53056In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-53057In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-53058In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-5306The Check & Log Email WordPress plugin before 2.0.13 does n…5.4
- CVE-2026-53060In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-53061In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-53062In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-53063In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-53064In the Linux kernel, the following vulnerability has been re…5.5
Are you affected by CVE-2026-53059?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
