Skip to content

CVE-2026-53059

Integer Overflow: Is CVE-2026-53059 real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Not listed
CISA KEV
Public exploit
None known
Metasploit/EDB/PoC
Base severity
6.3 Medium
CVSS
Exploitation prob.
0.1%
FIRST EPSS
Weakness
CWE-190 · Integer Overflow
CWE

Moderate signals. Triage by your actual exposure and reachability.

baseline read

auto · not a community verdict

Low signal — verdict needed

Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.

Based on CVSS · FIRST EPSS

Confirm or dispute →

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

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.

Published

Embed this verdict
TruePositive verdict for CVE-2026-53059
Markdown
[![TruePositive verdict](https://www.truepositive.app/cve/CVE-2026-53059/badge.svg)](https://www.truepositive.app/cve/CVE-2026-53059)
HTML
<a href="https://www.truepositive.app/cve/CVE-2026-53059"><img src="https://www.truepositive.app/cve/CVE-2026-53059/badge.svg" alt="TruePositive verdict for CVE-2026-53059"></a>

Live badge that updates automatically as the community verdict changes.

Community ground truth

Be the first practitioner to weigh in

So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.

🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.

In your experience, is this finding real and exploitable?

awaiting field verdicts
Real, but not a risk here
Not a real issue

Curated baseline: A curated baseline from public sources, shown separately from community verdicts.

No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.

Field notes & remediation

Verdicts are the quick signal. Notes are the evidence and fixes behind them.

  • 0
    Field note · TruePositive EditorialCurated

    No confirmed in-the-wild exploitation or public exploit was found for this yet.

Add a field note or remediationoptional
Note type

What are you adding?

Markdown supported · minimum 20 characters.

Same weakness: CWE-190 · Integer Overflow.