CVE-2026-46240

What it actually does

This is a Linux kernel use-after-free flaw in the Iris media driver’s internal buffer release path. A regression caused iris_release_internal_buffers() to continue using a buffer pointer after session_release_buf() may have freed it. A local authenticated attacker with access to the affected media device interface could potentially trigger the faulty cleanup sequence, causing kernel memory corruption. Depending on exploitability on a given build and hardware configuration, this may lead to denial of service through a kernel crash or, in a worst case, local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems using affected Linux kernels with the Iris media driver enabled may be exposed to local privilege escalation or crashes. The practical risk is highest on endpoints, appliances, embedded Linux devices, or media-processing systems where untrusted local users, applications, containers, or sandboxed workloads can access video/media device nodes. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel privilege escalation flaws can materially increase the impact of any prior foothold.

How an attack unfolds

An attacker first needs local code execution or an account on a system running an affected Linux kernel with the Iris media driver present and reachable. They then interact with the media subsystem, likely through video/media device nodes, to create and tear down a codec/media session in a way that exercises the internal buffer release path. During cleanup, the vulnerable code may free an internal buffer and then continue to access the stale pointer, corrupting kernel memory. A simple exploit may only crash the kernel, while a more sophisticated exploit would attempt to shape kernel heap state so the freed object is replaced with attacker-influenced data, potentially redirecting execution or modifying kernel data structures to gain elevated privileges.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the fix for the Iris media driver use-after-free in iris_release_internal_buffers(). No exact fixed versions were provided in the input, so organizations should rely on their Linux distribution, device vendor, or kernel supplier advisories and confirm the patch that sets BUF_ATTR_PENDING_RELEASE before session_release_buf() is included. Where immediate patching is not possible, reduce exposure by disabling or unloading the Iris media driver if it is not required, restricting access to /dev/video*, /dev/media*, and related device nodes, limiting local shell access, and preventing untrusted workloads from accessing host media devices. For containerized environments, avoid passing video/media devices into containers unless explicitly required.

How to confirm the fix worked

Confirm the deployed kernel package includes the upstream or vendor backport for the Iris media driver fix. Validate using vendor package changelogs, kernel source/package metadata, or advisory references rather than relying only on the kernel version string because distributions often backport security fixes. On representative systems, verify whether the Iris driver is loaded or available using commands such as lsmod, modinfo, and dmesg searches for iris/media driver initialization. Confirm that untrusted users and containers do not have unnecessary access to media device nodes. After patching, perform a controlled reboot if required by the kernel update process and verify the running kernel is the updated one, not merely the installed package.

Typical attack path

1. Obtain local user-level execution on a Linux system, such as through a shell, compromised application, malicious package, or escaped application sandbox prerequisite.
2. Determine whether the system runs an affected kernel and exposes the Iris media driver or related media/video device nodes to the attacker.
3. Open and interact with the media device interface to create a session and allocate internal buffers.
4. Trigger session teardown or buffer release behavior that reaches iris_release_internal_buffers() and session_release_buf().
5. Exploit the use-after-free condition to cause a kernel crash or manipulate kernel memory.
6. If reliable exploitation is possible, elevate privileges or execute code in kernel context.

How to detect it

To assess possible prior exploitation, review kernel logs and crash artifacts for evidence of use-after-free, kernel oops, KASAN reports, or panics involving the Iris media driver and buffer release functions. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, persistent pstore/ramoops records, kdump/vmcore artifacts, and EDR telemetry for local processes interacting with media device nodes. Look for unexpected access to /dev/video*, /dev/media*, or related device files by untrusted users, recently introduced binaries, browser helper processes, container runtimes, or media fuzzing tools. Since no public exploit or campaign is known from the provided data, detection should focus on behavioral signs: repeated media device open/ioctl activity followed by kernel instability, privilege changes after a crash, suspicious root-owned files created after media-driver faults, or local exploit tooling staged in temporary directories. If KASAN or kernel debugging was enabled, search for direct references to iris_release_internal_buffers(), session_release_buf(), use-after-free, slab corruption, or freed-object access.

• iris_release_internal_buffers
• session_release_buf
• use-after-free
• Use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• media: iris
• iris:
• /dev/video
• /dev/media
• /var/crash
• /sys/fs/pstore
• /proc/vmcore
• BUF_ATTR_PENDING_RELEASE

What your security team should do

• Prioritize patching systems where untrusted local users, desktop applications, browsers, media-processing workloads, or containers can access Linux media/video devices.
• Inventory Linux hosts and embedded devices for affected kernels and for Iris/media driver exposure.
• Apply distribution or vendor kernel updates that include the Iris driver use-after-free fix, then reboot into the updated kernel.
• Restrict permissions on /dev/video*, /dev/media*, and related device nodes to only trusted users and services.
• Avoid passing host media devices into containers or sandboxed workloads unless there is a clear operational requirement.
• Monitor for kernel crashes, KASAN use-after-free reports, and suspicious local probing of video/media device nodes.
• Treat exploitation suspicion as a potential local privilege escalation event and investigate for follow-on root-level persistence or credential theft.
• Because the issue is not KEV-listed, has no known public exploit maturity, and has low EPSS, schedule according to local exposure rather than as an emergency internet-facing vulnerability.