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.

Weakness

The product writes data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

• Be wary that a language’s interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

• Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

• Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

• D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

• Consider adhering to the following rules when allocating and managing an application’s memory:

• Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

• Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as “rebasing” (for Windows) and “prelinking” (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

• For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

• Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

• For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

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/errata/RHSA-2026:45114
• https://access.redhat.com/errata/RHSA-2026:45115
• https://access.redhat.com/errata/RHSA-2026:45116
• https://access.redhat.com/errata/RHSA-2026:45192
• https://access.redhat.com/errata/RHSA-2026:47248
• https://access.redhat.com/security/cve/CVE-2026-53059
• https://bugzilla.redhat.com/show_bug.cgi?id=2492277
• https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53059.json