Skip to main content
VulnerabilityPublished Updated

CVE-2026-43048: Linux kernel · Out-of-bounds Write

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 8.8 High · fixed in bd6e1d0230cca9575f5d118148f51e2a56b5373f : patch Linux kernel soon.

Data as of 26 Oct 2026, 14:18 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 24% 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 bd6e1d0230cca9575f5d118148f51e2a56b5373f, b37e6019fe420335d884e30535549a25f084e00d, 218b93b7e284de1aa40a53f8f130f84f7da38858 +2
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 1 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ cd6104572bca9e4afe0dcdb8ecd65ef90b01297b, < bd6e1d0230cca9575f5d118148f51e2a56b5373f
Fixed in
  • bd6e1d0230cca9575f5d118148f51e2a56b5373f
LinuxLinuxAffected
  • ≥ cd6104572bca9e4afe0dcdb8ecd65ef90b01297b, < b37e6019fe420335d884e30535549a25f084e00d
Fixed in
  • b37e6019fe420335d884e30535549a25f084e00d
LinuxLinuxAffected
  • ≥ cd6104572bca9e4afe0dcdb8ecd65ef90b01297b, < 218b93b7e284de1aa40a53f8f130f84f7da38858
Fixed in
  • 218b93b7e284de1aa40a53f8f130f84f7da38858
LinuxLinuxAffected
  • ≥ cd6104572bca9e4afe0dcdb8ecd65ef90b01297b, < 8f71034649738fdeb6859b8d6cddf132024fac06
Fixed in
  • 8f71034649738fdeb6859b8d6cddf132024fac06
LinuxLinuxAffected
  • ≥ cd6104572bca9e4afe0dcdb8ecd65ef90b01297b, < 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c
Fixed in
  • 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c
LinuxLinuxAffected
  • =2.6.15
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: HID: core: Mitigate potential OOB by removing bogus memset() The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution. The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report. Suggested-by Benjamin Tissoires <bentiss@kernel.org> [bentiss: changed the return value]

References

Community reviews

Loading reviews…