GHSA-RRM5-VQ26-9V4C
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2025-09-25 21:30In the Linux kernel, the following vulnerability has been resolved:
can: isotp: fix potential CAN frame reception race in isotp_rcv()
When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage.
Ziyang Xuan writes:
The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put().
======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579
Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation.
{
"affected": [],
"aliases": [
"CVE-2022-48830"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: isotp: fix potential CAN frame reception race in isotp_rcv()\n\nWhen receiving a CAN frame the current code logic does not consider\nconcurrently receiving processes which do not show up in real world\nusage.\n\nZiyang Xuan writes:\n\nThe following syz problem is one of the scenarios. so-\u003erx.len is\nchanged by isotp_rcv_ff() during isotp_rcv_cf(), so-\u003erx.len equals\n0 before alloc_skb() and equals 4096 after alloc_skb(). That will\ntrigger skb_over_panic() in skb_put().\n\n=======================================================\nCPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0\nRIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113\nCall Trace:\n \u003cTASK\u003e\n skb_over_panic net/core/skbuff.c:118 [inline]\n skb_put.cold+0x24/0x24 net/core/skbuff.c:1990\n isotp_rcv_cf net/can/isotp.c:570 [inline]\n isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668\n deliver net/can/af_can.c:574 [inline]\n can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635\n can_receive+0x31d/0x580 net/can/af_can.c:665\n can_rcv+0x120/0x1c0 net/can/af_can.c:696\n __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465\n __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579\n\nTherefore we make sure the state changes and data structures stay\nconsistent at CAN frame reception time by adding a spin_lock in\nisotp_rcv(). This fixes the issue reported by syzkaller but does not\naffect real world operation.",
"id": "GHSA-rrm5-vq26-9v4c",
"modified": "2025-09-25T21:30:19Z",
"published": "2024-07-16T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48830"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b068f33bc8acfcfd5ea7992a2dafb30d89bad30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b53d2204ce79b27a878074a77d64f40ec21dbca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c759040c1dd03954f650f147ae7175476d51314"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f90cc68f9f4b5d8585ad5d0a206a9d37ac299ef3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/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.