CVE-2026-53025

What it actually does

This is a Linux kernel use-after-free flaw in the Greybus raw character-device handling path. If a Greybus raw bundle is disconnected while an application still has the associated character device open, the kernel can free the underlying gb_raw structure before the final close path releases the cdev reference. A later close then operates on freed memory, triggering refcount underflow warnings and potentially a kernel panic. The described failure mode is denial of service through a local kernel crash; practical privilege escalation is not indicated by the available details.

Why it matters to the business

Systems that use the Linux Greybus raw driver can be crashed by triggering a specific device-disconnect and file-close sequence, causing service interruption and possible data loss from abrupt reboot or kernel panic. Overall public exploitation likelihood appears low at this time because EPSS is very low, the issue is not listed in CISA KEV, no ransomware use is reported, and no mature public exploit is indicated. The business risk is highest for embedded, mobile, development, or specialized Linux systems where Greybus support is enabled and accessible to local users or applications.

How an attack unfolds

An attacker first needs local ability to interact with a Greybus raw character device on a vulnerable kernel. They open the raw character device and keep the file descriptor active. The attacker or a controlled device event then causes the corresponding Greybus raw bundle to disconnect, which triggers the vulnerable cleanup path and frees the gb_raw object even though the character device is still referenced. When the attacker closes the previously opened file descriptor, the kernel release path calls into cdev cleanup using memory that has already been freed. On vulnerable builds this can produce a refcount underflow warning and kernel panic, resulting in denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream Greybus raw lifetime-management fix for this issue. The fix changes the lifetime relationship between the device and cdev by embedding the struct device, using cdev_device_add(), and deferring gb_raw structure freeing to the device release function. If distribution-specific fixed kernel versions are not yet available, track the vendor advisory for the affected distribution or kernel branch and upgrade to the first kernel package that includes the CVE-2026-53025 fix. As interim mitigation, disable or unload the Greybus raw driver where it is not required, restrict local access to Greybus raw character devices, and limit untrusted local code execution on systems with Greybus enabled.

How to confirm the fix worked

Confirm the running kernel version includes the vendor or upstream fix for the Greybus raw use-after-free. Review kernel configuration and loaded modules to determine whether Greybus raw support is present, for example by checking kernel config for Greybus raw options and loaded Greybus-related modules. Validate that no unnecessary Greybus raw character devices are exposed to untrusted users and that device permissions are restrictive. In a controlled non-production test environment only, reproduce the disconnect-while-open scenario and confirm the system no longer logs refcount underflow or use-after-free warnings and does not panic when the character device is closed after disconnect.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the Greybus raw driver enabled and a reachable Greybus raw character device.
2. Obtain local execution or the ability to run an application that can open the Greybus raw character device.
3. Open the Greybus raw character device and keep the file descriptor open.
4. Trigger or wait for disconnection of the associated Greybus raw bundle while the character device remains open.
5. Close the still-open file descriptor after the disconnect.
6. Cause the kernel to dereference or release freed cdev-related memory, leading to refcount warnings and possible kernel panic.

How to detect it

Review historical kernel logs, system journals, crash dumps, and panic reports for signs of the Greybus raw close-after-disconnect failure. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, pstore records, kdump/vmcore analysis, and any centralized Linux kernel log collection. Look for refcount underflow warnings, use-after-free messages, cdev_put in stack traces, __x64_sys_close or __fput near the crash path, and Greybus raw disconnect activity preceding a kernel panic or reboot. Also correlate unexpected reboots or watchdog resets with local processes that had Greybus raw character devices open. There are no public threat actors or ransomware campaigns reported for this issue, so detection should focus on kernel crash artifacts rather than known adversary infrastructure.

• refcount_t: underflow; use-after-free.
• WARNING: CPU: 0 PID:
• refcount_warn_saturate
• cdev_put+0x18/0x30
• __fput+0x255/0x2a0
• __x64_sys_close+0x3d/0x80
• entry_SYSCALL_64_after_hwframe
• greybus: raw
• gb_raw
• CONFIG_INIT_ON_FREE_DEFAULT_ON=y

What your security team should do

• Prioritize patching Linux systems that enable Greybus or expose Greybus raw character devices, especially embedded, lab, mobile, or hardware-development systems.
• Inventory kernels and configurations for Greybus raw support; deprioritize systems where Greybus is not built, not loaded, and no related character devices exist.
• Apply distribution kernel updates as soon as they become available and reboot systems to ensure the fixed kernel is running.
• Where Greybus raw is not needed, disable the driver or prevent the module from loading.
• Restrict permissions on Greybus raw character devices so only trusted system components or administrators can access them.
• Monitor kernel logs for refcount underflow, use-after-free, cdev, and Greybus disconnect events that may indicate attempted triggering.
• Because the issue is not in KEV, has very low EPSS, and has no known mature exploit, handle through normal kernel vulnerability maintenance unless Greybus is exposed in safety-critical or high-availability systems.