← Back to articles
Security· 3 min read

CVE-2026-23236: smscufx driver lets an unprivileged user corrupt kernel memory

The Linux kernel carried a silly but dangerous mistake in smscufx, the framebuffer driver for USB-to-video adapters built on SMSC UFX chips. The handler for the UFX_IOCTL_REPORT_DAMAGE ioctl took a structure from userspace and, instead of copying it in with copy_from_user() the way kernel code is supposed to, dereferenced the pointer the process handed it directly. Whoever controls that pointer controls which address the kernel reads from and writes to.

The outcome is what you’d expect from a driver that blindly trusts a userspace address: kernel memory corruption and a system crash. It was assigned CVE-2026-23236 and published on 4 March 2026.

Who is affected

The bug sits in the driver code itself, so it affects any Linux system that has smscufx built and loaded. It’s an uncommon framebuffer module these days (used with older DisplayLink/SMSC adapters), but many distributions ship it as a loadable module. If the module isn’t present and can’t be loaded, you aren’t exposed through this path.

The version range is huge because the flaw has been there since the start. NVD lists affected branches from 3.2 all the way through modern series: 5.10 up to 5.10.250, 5.15 up to 5.15.200, 6.1 up to 6.1.163, 6.6 up to 6.6.126, 6.12 up to 6.12.73 and 6.19 up to 6.19.2, among others. If your kernel predates the fixed point of its branch, check whether the module is in play.

Severity

The scores differ depending on who assigned them. NIST rates it 5.5 (medium) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, focused on the availability impact. The kernel.org CNA goes higher, 7.3 (high) with AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H, also accounting for controlled writes into kernel memory.

The gap makes sense. A denial of service that takes the machine down is already serious; but if an attacker can write to specific kernel regions through a pointer they supply, the potential goes beyond a hang. Either way the attack is local: it needs an account on the machine and access to the framebuffer device. It can’t be triggered over the network.

Mitigation and patch

The fix does the obvious thing that was missing: copy the data in from userspace with the safe routine before touching it in the kernel, rather than dereferencing the user’s pointer. Patches went out across the stable branches (among the commits, 061cfeb560aa3ddc174153dbe5be9d0b55eb7248).

What to do:

  • Update the kernel to the fixed point of your branch. On a supported distribution, install the kernel package that carries this patch.
  • If you don’t need smscufx, unload it and blacklist it. Add blacklist smscufx under /etc/modprobe.d/ and confirm with lsmod | grep smscufx that it isn’t loaded. It’s a clean stopgap until the update lands.
  • Restrict who can reach the /dev/fb* devices if your setup allows it.

As always with local kernel flaws, the real risk tracks how many people have a shell on the box. On a multi-user server or shared hosts, prioritise it; on a single-user machine you have more room, but patching is still the right call.

You can check the support status of each kernel series on our Linux kernel page.

Source

Related systems

Linux Kernel