# CVE-2026-23236: smscufx driver lets an unprivileged user corrupt kernel memory - **Published on:** 2026-03-04 - **Category:** Security - **Original page:** https://linuxgratis.com/en/articles/cve-2026-23236-smscufx-fbdev-corrupcion-kernel-linux The Linux kernel's smscufx framebuffer driver dereferenced a userspace pointer instead of copying it in first. A local user could corrupt kernel memory and crash the box. Here's who's affected and how to patch. --- 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](/en/linux-kernel) page. ## Source - NVD — CVE-2026-23236: