CVE-2026-53059

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.

CVSS v3.1 Score

7.0

HIGH

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS — Exploit Prediction

0.0013

Probability of exploitation

0.03%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

Weakness Type (CWE)

CWE-190 Integer Overflow

References

Other References

https://git.kernel.org/stable/c/12bd5b88e91a02785244ff1d20fb157e96e9cdc8 https://git.kernel.org/stable/c/3ec74da927b4e171a6fc0e77b1188ba4d019af51 https://git.kernel.org/stable/c/44ab8875ae4a2842bde2d756bed195d375e0debb https://git.kernel.org/stable/c/4ec8323b9f0764a14d532b1ae9b87f8a9fecb867 https://git.kernel.org/stable/c/b455903eed4558982be0811f5b7f44f6bbc4ff57 https://git.kernel.org/stable/c/c20e36b7631d83e7535877f08af8b0af72c44b1a https://git.kernel.org/stable/c/d4ac87567f86a55c3c92e9a5144dcd943a9772a1 https://git.kernel.org/stable/c/defe483e47173768c227532694dc78cb65db5f09 https://access.redhat.com/security/cve/CVE-2026-53059 https://bugzilla.redhat.com/show_bug.cgi?id=2492277

Frequently Asked Questions

What is CVE-2026-53059? +

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. It has a CVSS v3.1 base score of 7.0 (HIGH).

How severe is CVE-2026-53059? +

CVE-2026-53059 has a CVSS v3.1 score of 7.0 out of 10, rated HIGH. This is a high-severity vulnerability that should be prioritized for patching. The EPSS score is 0.0013, placing it in the 0th percentile for exploitation probability.

How do I check if I'm vulnerable to CVE-2026-53059? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-2574

Out-of-bounds array write in Xpdf 4.05 and earlier, due to incorrect integer overflow checking in the PostScript function interpreter code.

CVE-2025-46333

z2d is a pure Zig 2D graphics library. Versions of z2d after `0.5.1` and up to and including `0.6.0`, when …

CVE-2024-30212

If a SCSI READ(10) command is initiated via USB using the largest LBA (0xFFFFFFFF) with it's default block size of …

CVE-2025-52935

Integer Overflow or Wraparound vulnerability in dragonflydb dragonfly (src/redis/lua/struct modules). This vulnerability is associated with program files lua_struct.C. This issue …

CVE-2025-7709

An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers …

CVE-2025-34297

KissFFT versions prior to the fix commit 1b083165 contain an integer overflow in kiss_fft_alloc() in kiss_fft.c on platforms where size_t …