CVE-2026-53158

Linux kernel: null pointer dereference

Risk score: 48/100
CVSS: 5.5 v3.1
Exploit chance (30 days): 0.1%
Published: 25 Jun 2026

Open in the live forecast Today's forecast

What to know

What it is: In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer de…
Affected: Linux kernel
Fix: Apply the vendor's security update; see the linked advisory.
Exploitation: No known exploitation

Story map

Story map: the flaws, the fix, how it unfolded and what it connects to. Boxes link to the record or article.

At a glance

Linux kernel: Amber, patch this week. In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the …

The flaws

CVE-2026-53158: Null pointer dereference (CVSS 5.5 · EPSS 0%)
CVE-2026-98096: Out-of-bounds write (CVSS 7.4 · EPSS 1%)
CVE-2026-98115: Race condition (CVSS 8.8 · EPSS 0%)
CVE-2026-98117: Use-after-free (CVSS 7.8 · EPSS 0%)

The fix

Fix: Apply the vendor's security update; see the linked advisory.

Who is exposed: Linux kernel

Where it stands

No known exploitation

How it unfolded

6 Nov, Ubuntu security notices (official): USN-9002-1: Linux kernel (NVIDIA Tegra) vulnerabilities

Connects to

Same weakness: Null pointer dereference (CWE-476). 148 other warnings in 30 days
Same product: Earlier Linux kernel warnings. 168 in the last 90 days

Why it is Yellow

CVSS 5.5 medium
On your watchlist: linux kernel
Named in a government or vendor bulletin

Government and vendor bulletins

USN-9002-1: Linux kernel (NVIDIA Tegra) vulnerabilities

References

Original description

In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.

Last activity 6 Nov 2026. Patch Forecast updates every hour.