CVE-2026-43497

What it actually does

This is a local Linux kernel use-after-free in the udlfb DisplayLink USB framebuffer driver. The vulnerable mmap path maps vmalloc-backed framebuffer memory into a userspace process without registering VMA open/close callbacks, so the kernel does not know that userspace still holds active mappings. If the framebuffer backing buffer is reallocated through framebuffer configuration changes and the USB device is later disconnected or destroyed, the old framebuffer pages can be freed while userspace page table entries still reference them. A local attacker with access to the framebuffer device can retain read/write access to freed kernel memory, potentially enabling kernel memory disclosure, memory corruption, privilege escalation, or system crash.

Why it matters to the business

Successful exploitation can allow a low-privileged local user to gain kernel-level control or disrupt the host. Systems are most exposed where the udlfb driver is present and untrusted users can access framebuffer devices, including desktop Linux systems, kiosks, lab workstations, thin clients, systems using USB DisplayLink adapters, or environments where USB device emulation is possible. Although EPSS is currently very low and the issue is not listed in CISA KEV, the impact is high because exploitation can cross the boundary from a normal local account to full operating-system compromise.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user on a Linux system where the udlfb framebuffer driver is loaded or can be triggered by a DisplayLink-compatible USB device. The attacker opens the affected framebuffer device and creates a userspace mmap of the framebuffer. They then trigger a framebuffer reconfiguration path, such as changing virtual screen information through the framebuffer ioctl interface, causing the driver to replace the backing framebuffer memory without invalidating the existing userspace mapping. After device teardown or USB disconnect causes the old buffer to be freed, the attacker continues using the stale mapping, which still points at freed kernel pages. With careful heap manipulation, those freed pages may be reused for other kernel objects, letting the attacker read or overwrite kernel memory. Depending on kernel hardening and heap layout, this can result in privilege escalation, sensitive memory disclosure, or a denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the udlfb fix adding vm_operations_struct open/close tracking and preventing framebuffer reallocation while mappings are active. If fixed package versions are not yet available from the distribution, apply the upstream kernel patch or use a vendor-supported kernel containing the correction. As interim mitigation, unload or blacklist the udlfb kernel module if DisplayLink USB framebuffer support is not required, restrict physical and logical USB device attachment, and limit access to framebuffer device nodes such as /dev/fb* to trusted users only. Consider disabling unneeded framebuffer/USB display support in hardened server builds.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not only that the package is installed on disk. Check whether the udlfb module is present or loaded using tools such as lsmod, modinfo, and kernel configuration inspection. Verify permissions on /dev/fb* do not allow untrusted local users to open or mmap framebuffer devices. On patched systems, attempts to reallocate the udlfb framebuffer while it is actively mmaped should fail safely, for example returning a busy condition rather than replacing the backing buffer. Also validate that blacklisting or module removal persists across reboot if mitigation rather than patching is used.

Typical attack path

1. Gain local access to a Linux host as a low-privileged user.
2. Identify that the udlfb DisplayLink framebuffer driver is loaded or arrange for a compatible USB framebuffer device to bind to it.
3. Open the associated framebuffer device, commonly under /dev/fb*.
4. Create a userspace mmap of the framebuffer memory.
5. Trigger framebuffer reallocation through framebuffer configuration changes such as FBIOPUT_VSCREENINFO.
6. Cause device teardown or USB disconnect so the old framebuffer pages are freed.
7. Continue accessing the stale userspace mapping that references freed kernel memory.
8. Use the stale mapping to disclose or corrupt kernel memory, potentially escalating privileges or crashing the system.

How to detect it

Retrospective detection is difficult because successful exploitation occurs through local kernel memory misuse and may not leave a single definitive log entry. Focus on correlating local user activity with udlfb driver loading, framebuffer device access, framebuffer reconfiguration, USB DisplayLink attach/detach events, and kernel instability. Review kernel logs, auditd logs, EDR telemetry, udev logs, shell history where available, and system authentication logs. Look for unexpected access to /dev/fb*, use of framebuffer ioctls such as FBIOPUT_VSCREENINFO by non-display processes, unusual membership or access by users in groups that can open framebuffer devices, unexpected loading of udlfb, dummy_hcd, or raw_gadget modules, and USB disconnect events immediately followed by kernel warnings, oopses, general protection faults, page faults, slab corruption, privilege changes, or suspicious root shell execution. If auditd is enabled, search for open, mmap, and ioctl activity against framebuffer device nodes. On systems with kernel crash dumps, inspect traces mentioning udlfb, dlfb_ops_mmap, dlfb_realloc_framebuffer, dlfb_ops_destroy, remap_pfn_range, vfree, or framebuffer ioctl paths.

• udlfb
• dlfb_ops_mmap
• dlfb_realloc_framebuffer
• dlfb_ops_destroy
• remap_pfn_range
• FBIOPUT_VSCREENINFO
• /dev/fb0
• /dev/fb1
• /dev/fb2
• /dev/fb*
• DisplayLink
• usbcore: registered new interface driver udlfb
• udlfb:
• dummy_hcd
• raw_gadget
• general protection fault
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• kernel BUG
• Oops:
• use-after-free
• KASAN: use-after-free
• slab-use-after-free
• vfree
• ioctl FBIOPUT_VSCREENINFO

What your security team should do

• Prioritize patching systems that load udlfb, use USB DisplayLink adapters, expose framebuffer devices to non-admin users, or allow local shell access by untrusted users.
• Inventory Linux endpoints and servers for loaded or available udlfb support using lsmod, modinfo, kernel package metadata, and endpoint management telemetry.
• Restrict permissions on /dev/fb* and review group memberships that grant framebuffer access, such as video or console-related groups.
• Disable or blacklist udlfb on systems that do not require USB DisplayLink framebuffer functionality.
• Harden USB device policy on workstations and kiosks, especially where users can attach arbitrary USB devices.
• Monitor for suspicious framebuffer ioctl usage, unexpected udlfb loads, USB DisplayLink device attachment, dummy_hcd/raw_gadget use, kernel oops messages, and local privilege escalation artifacts.
• Treat suspicious kernel crashes or privilege changes involving framebuffer or USB display activity as potential exploitation attempts, even though public exploitation is not currently reported.