Linux Kernel CVE-2026-53024

Requires the Greybus 'raw' driver (gb_raw) to be loaded and its character device present and accessible, plus a local account with permission to write() to that chardev (PR:L). The decisive trigger is timing: the write must reach gb_operation_sync_timeout() after disconnect has called gb_connection_destroy() and freed the gb_connection - i.e., the attacker must race a write against device/bundle removal, so it depends on a removable or removed Greybus device. Limiting factors that reduce realistic risk: exploitation is local-only (no network vector), demonstrated impact is a kernel panic / denial of service rather than confirmed code execution, the gb_raw driver is a niche component not loaded in typical deployments, and success depends on hitting a write/disconnect race window rather than a deterministic single request.

The vendor CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) rates this High, but the supporting signals point to a more contained denial-of-service issue than the full C:H/I:H/A:H triad implies: the reproduction is a kernel NULL pointer dereference panic, and the intelligence tags explicitly label it 'Denial Of Service'. EPSS is very low (0.16%, 6th percentile), there is no KEV listing and no public exploit identified, consistent with low real-world exploitation pressure. Two caveats should be stated explicitly: (1) the CVSS scores AC:L, but the underlying defect is a race between write and disconnect, so practical exploitation requires winning a timing window - real attack complexity is arguably higher than AC:L suggests. (2) The official C:H/I:H impact is the conservative kernel-UAF maximum; the available evidence only demonstrates a crash/DoS, so confidentiality/integrity impact beyond a panic is not confirmed. Net: a legitimate stability/availability bug worth patching during normal kernel update cycles, but not an emergency given local-only access, niche driver, and absence of exploitation evidence.

A local user with read/write access to the Greybus raw character device opens it and, during or immediately after the corresponding Greybus device/bundle is removed (disconnect), issues a write() so that raw_write() calls into gb_operation_sync_timeout() with a connection object that gb_connection_destroy() has just freed. The freed-then-reused (zeroed under CONFIG_INIT_ON_FREE_DEFAULT_ON) connection triggers a NULL pointer dereference and kernel panic, taking the system down. No public proof-of-concept is identified at time of analysis.