GHSA-J24M-W36C-325G
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-07 21:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-53158"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix NULL pointer dereference in rpmsg callback\n\nA NULL pointer dereference was observed on Hawi at boot when the DSP\nsends a glink message before fastrpc_rpmsg_probe() has completed\ninitialization:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178\n pc : _raw_spin_lock_irqsave+0x34/0x8c\n lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]\n ...\n Call trace:\n _raw_spin_lock_irqsave+0x34/0x8c (P)\n fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]\n qcom_glink_native_rx+0x538/0x6a4\n qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem]\n\nThe faulting address 0x178 corresponds to the lock variable inside\nstruct fastrpc_channel_ctx, confirming that cctx is NULL when\nfastrpc_rpmsg_callback() attempts to take the spinlock.\n\nThere are two issues here. First, dev_set_drvdata() is called before\nspin_lock_init() and idr_init(), leaving a window where the callback\ncan retrieve a valid cctx pointer but operate on an uninitialized\nspinlock. Second, the rpmsg channel becomes live as soon as the driver\nis bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata()\nis called at all, resulting in dev_get_drvdata() returning NULL.\n\nFix both issues by moving all cctx initialization ahead of\ndev_set_drvdata() so the structure is fully initialized before it\nbecomes visible to the callback, and add a NULL check in\nfastrpc_rpmsg_callback() as a guard against any remaining window.",
"id": "GHSA-j24m-w36c-325g",
"modified": "2026-07-07T21:31:30Z",
"published": "2026-06-25T09:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53158"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d8c64511fd45690c5326f013710efcb4f73a97e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/150bf6f1193c69252580c19d3b3cd631ddce61d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bfdf0a9855df55e9e031ca6a25b855820590c70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5401fb4fe10fac6134c308495df18ed74aebb9c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fb4a23df5b7c02929b62e5dbc270ec7c42b8134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d91218ccca1e990bfb737b5a6da23f0afba22b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5de9cb5355db36438edc621dde3673e3f235767"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d77583ca33299fede0c194744ef2284e7ba5b763"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.