CVE-2023-53836 (GCVE-0-2023-53836)
Vulnerability from cvelistv5 – Published: 2025-12-09 01:29 – Updated: 2025-12-09 01:29
VLAI?
Title
bpf, sockmap: Fix skb refcnt race after locking changes
Summary
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix skb refcnt race after locking changes
There is a race where skb's from the sk_psock_backlog can be referenced
after userspace side has already skb_consumed() the sk_buff and its refcnt
dropped to zer0 causing use after free.
The flow is the following:
while ((skb = skb_peek(&psock->ingress_skb))
sk_psock_handle_Skb(psock, skb, ..., ingress)
if (!ingress) ...
sk_psock_skb_ingress
sk_psock_skb_ingress_enqueue(skb)
msg->skb = skb
sk_psock_queue_msg(psock, msg)
skb_dequeue(&psock->ingress_skb)
The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is
what the application reads when recvmsg() is called. An application can
read this anytime after the msg is placed on the queue. The recvmsg hook
will also read msg->skb and then after user space reads the msg will call
consume_skb(skb) on it effectively free'ing it.
But, the race is in above where backlog queue still has a reference to
the skb and calls skb_dequeue(). If the skb_dequeue happens after the
user reads and free's the skb we have a use after free.
The !ingress case does not suffer from this problem because it uses
sendmsg_*(sk, msg) which does not pass the sk_buff further down the
stack.
The following splat was observed with 'test_progs -t sockmap_listen':
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
[ 1022.713653][ T2556] Code: ...
[...]
[ 1022.720699][ T2556] Call Trace:
[ 1022.720984][ T2556] <TASK>
[ 1022.721254][ T2556] ? die_addr+0x32/0x80^M
[ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0
[ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30
[ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80
[ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300
[ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0
[ 1022.723633][ T2556] worker_thread+0x4f/0x3a0
[ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10
[ 1022.724386][ T2556] kthread+0xfd/0x130
[ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725066][ T2556] ret_from_fork+0x2d/0x50
[ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30
[ 1022.726201][ T2556] </TASK>
To fix we add an skb_get() before passing the skb to be enqueued in the
engress queue. This bumps the skb->users refcnt so that consume_skb()
and kfree_skb will not immediately free the sk_buff. With this we can
be sure the skb is still around when we do the dequeue. Then we just
need to decrement the refcnt or free the skb in the backlog case which
we do by calling kfree_skb() on the ingress case as well as the sendmsg
case.
Before locking change from fixes tag we had the sock locked so we
couldn't race with user and there was no issue here.
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3 , < 65ad600b9bde68d2d28709943ab00b51ca8f0a1d
(git)
Affected: 799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3 , < 923877254f002ae87d441382bb1096d9e773d56d (git) Affected: 799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3 , < e6b5e47adb9166e732cdf7e6e034946e3f89f36d (git) Affected: 799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3 , < a454d84ee20baf7bd7be90721b9821f73c7d23d9 (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "65ad600b9bde68d2d28709943ab00b51ca8f0a1d",
"status": "affected",
"version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
"versionType": "git"
},
{
"lessThan": "923877254f002ae87d441382bb1096d9e773d56d",
"status": "affected",
"version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
"versionType": "git"
},
{
"lessThan": "e6b5e47adb9166e732cdf7e6e034946e3f89f36d",
"status": "affected",
"version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
"versionType": "git"
},
{
"lessThan": "a454d84ee20baf7bd7be90721b9821f73c7d23d9",
"status": "affected",
"version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.13"
},
{
"lessThan": "5.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.189",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.54",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.189",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.54",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.4",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "5.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix skb refcnt race after locking changes\n\nThere is a race where skb\u0027s from the sk_psock_backlog can be referenced\nafter userspace side has already skb_consumed() the sk_buff and its refcnt\ndropped to zer0 causing use after free.\n\nThe flow is the following:\n\n while ((skb = skb_peek(\u0026psock-\u003eingress_skb))\n sk_psock_handle_Skb(psock, skb, ..., ingress)\n if (!ingress) ...\n sk_psock_skb_ingress\n sk_psock_skb_ingress_enqueue(skb)\n msg-\u003eskb = skb\n sk_psock_queue_msg(psock, msg)\n skb_dequeue(\u0026psock-\u003eingress_skb)\n\nThe sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is\nwhat the application reads when recvmsg() is called. An application can\nread this anytime after the msg is placed on the queue. The recvmsg hook\nwill also read msg-\u003eskb and then after user space reads the msg will call\nconsume_skb(skb) on it effectively free\u0027ing it.\n\nBut, the race is in above where backlog queue still has a reference to\nthe skb and calls skb_dequeue(). If the skb_dequeue happens after the\nuser reads and free\u0027s the skb we have a use after free.\n\nThe !ingress case does not suffer from this problem because it uses\nsendmsg_*(sk, msg) which does not pass the sk_buff further down the\nstack.\n\nThe following splat was observed with \u0027test_progs -t sockmap_listen\u0027:\n\n [ 1022.710250][ T2556] general protection fault, ...\n [...]\n [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog\n [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80\n [ 1022.713653][ T2556] Code: ...\n [...]\n [ 1022.720699][ T2556] Call Trace:\n [ 1022.720984][ T2556] \u003cTASK\u003e\n [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M\n [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0\n [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30\n [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80\n [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300\n [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0\n [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0\n [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10\n [ 1022.724386][ T2556] kthread+0xfd/0x130\n [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10\n [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50\n [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10\n [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30\n [ 1022.726201][ T2556] \u003c/TASK\u003e\n\nTo fix we add an skb_get() before passing the skb to be enqueued in the\nengress queue. This bumps the skb-\u003eusers refcnt so that consume_skb()\nand kfree_skb will not immediately free the sk_buff. With this we can\nbe sure the skb is still around when we do the dequeue. Then we just\nneed to decrement the refcnt or free the skb in the backlog case which\nwe do by calling kfree_skb() on the ingress case as well as the sendmsg\ncase.\n\nBefore locking change from fixes tag we had the sock locked so we\ncouldn\u0027t race with user and there was no issue here."
}
],
"providerMetadata": {
"dateUpdated": "2025-12-09T01:29:52.004Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/65ad600b9bde68d2d28709943ab00b51ca8f0a1d"
},
{
"url": "https://git.kernel.org/stable/c/923877254f002ae87d441382bb1096d9e773d56d"
},
{
"url": "https://git.kernel.org/stable/c/e6b5e47adb9166e732cdf7e6e034946e3f89f36d"
},
{
"url": "https://git.kernel.org/stable/c/a454d84ee20baf7bd7be90721b9821f73c7d23d9"
}
],
"title": "bpf, sockmap: Fix skb refcnt race after locking changes",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-53836",
"datePublished": "2025-12-09T01:29:52.004Z",
"dateReserved": "2025-12-09T01:27:17.826Z",
"dateUpdated": "2025-12-09T01:29:52.004Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2023-53836\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-09T16:17:22.887\",\"lastModified\":\"2025-12-09T18:37:13.640\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf, sockmap: Fix skb refcnt race after locking changes\\n\\nThere is a race where skb\u0027s from the sk_psock_backlog can be referenced\\nafter userspace side has already skb_consumed() the sk_buff and its refcnt\\ndropped to zer0 causing use after free.\\n\\nThe flow is the following:\\n\\n while ((skb = skb_peek(\u0026psock-\u003eingress_skb))\\n sk_psock_handle_Skb(psock, skb, ..., ingress)\\n if (!ingress) ...\\n sk_psock_skb_ingress\\n sk_psock_skb_ingress_enqueue(skb)\\n msg-\u003eskb = skb\\n sk_psock_queue_msg(psock, msg)\\n skb_dequeue(\u0026psock-\u003eingress_skb)\\n\\nThe sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is\\nwhat the application reads when recvmsg() is called. An application can\\nread this anytime after the msg is placed on the queue. The recvmsg hook\\nwill also read msg-\u003eskb and then after user space reads the msg will call\\nconsume_skb(skb) on it effectively free\u0027ing it.\\n\\nBut, the race is in above where backlog queue still has a reference to\\nthe skb and calls skb_dequeue(). If the skb_dequeue happens after the\\nuser reads and free\u0027s the skb we have a use after free.\\n\\nThe !ingress case does not suffer from this problem because it uses\\nsendmsg_*(sk, msg) which does not pass the sk_buff further down the\\nstack.\\n\\nThe following splat was observed with \u0027test_progs -t sockmap_listen\u0027:\\n\\n [ 1022.710250][ T2556] general protection fault, ...\\n [...]\\n [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog\\n [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80\\n [ 1022.713653][ T2556] Code: ...\\n [...]\\n [ 1022.720699][ T2556] Call Trace:\\n [ 1022.720984][ T2556] \u003cTASK\u003e\\n [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M\\n [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0\\n [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30\\n [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80\\n [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300\\n [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0\\n [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0\\n [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10\\n [ 1022.724386][ T2556] kthread+0xfd/0x130\\n [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10\\n [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50\\n [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10\\n [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30\\n [ 1022.726201][ T2556] \u003c/TASK\u003e\\n\\nTo fix we add an skb_get() before passing the skb to be enqueued in the\\nengress queue. This bumps the skb-\u003eusers refcnt so that consume_skb()\\nand kfree_skb will not immediately free the sk_buff. With this we can\\nbe sure the skb is still around when we do the dequeue. Then we just\\nneed to decrement the refcnt or free the skb in the backlog case which\\nwe do by calling kfree_skb() on the ingress case as well as the sendmsg\\ncase.\\n\\nBefore locking change from fixes tag we had the sock locked so we\\ncouldn\u0027t race with user and there was no issue here.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/65ad600b9bde68d2d28709943ab00b51ca8f0a1d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/923877254f002ae87d441382bb1096d9e773d56d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a454d84ee20baf7bd7be90721b9821f73c7d23d9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e6b5e47adb9166e732cdf7e6e034946e3f89f36d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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.
Loading…
Loading…