CVE-2026-23236: fbdev: smscufx: properly copy ioctl memory to kernelspace
In the Linux kernel, the following vulnerability has been resolved:
fbdev: smscufx: properly copy ioctl memory to kernelspace
The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from
userspace to kernelspace, and instead directly references the memory,
which can cause problems if invalid data is passed from userspace. Fix
this all up by correctly copying the memory before accessing it within
the kernel.
Security readout for executives and security teams
Plain-English summary
A Linux framebuffer driver uses caller-controlled memory directly when processing damage reports instead of first copying it into kernel memory. A low-privileged local user with device access may supply invalid data, potentially compromising system integrity or availability. This is not described as a remote vulnerability.
Executive priority
Treat this as a high-priority local privilege-boundary issue on exposed multi-user systems and products using smscufx hardware. Accelerate patching where untrusted users or workloads can access the framebuffer device. Systems without the driver or accessible device interface have substantially lower urgency based on the supplied evidence.
Technical view
The smscufx UFX_IOCTL_REPORT_DAMAGE handler improperly references userspace memory. Listed stable commits copy the data before kernel access. The CVSS 3.1 score is 7.3: local, low-complexity, low-privilege exploitation requiring no user interaction, with modeled low confidentiality and high integrity and availability impact.
Likely exposure
Exposure is limited to Linux systems where the smscufx framebuffer driver is present and a low-privileged local user can reach the affected ioctl. The supplied version data is ambiguous and should not be treated as a reliable range; confirm each distribution kernel's backport status.
Exploitation context
The supplied record marks KEV false, and no cited source reports active exploitation or a public exploit. Exploitation requires local access, low privileges, and access to the affected driver interface. Absence of reported exploitation does not establish that exploitation is impossible.
Researcher notes
The remediation changes userspace-data handling in the ioctl path. No CWE is assigned, and the bundle provides no crash trace, proof of concept, or confirmed exploitation. The affected-version list contains ambiguous entries and repeated commit hashes; validate commit ancestry and downstream backports rather than relying on those strings alone.
Mitigation direction
Apply a distribution or vendor kernel update containing the appropriate listed stable fix.
Prioritize multi-user or appliance systems where untrusted local users can access smscufx devices.
Until updated, restrict untrusted local access to affected framebuffer devices where operationally safe.
Review vendor advisories for branch-specific fixed versions, backports, and reboot requirements.
Validation and detection
Inventory kernels with the smscufx driver built, installed, or loaded.
Determine whether untrusted local users can access the associated framebuffer device and ioctl.
Match distribution changelogs or kernel source against one of the listed stable fix commits.
Confirm the running kernel after updating, including any required reboot.
Review monitoring for related kernel faults without attempting malformed-input exploitation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23236 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.