GSD-2024-26624
Vulnerability from gsd - Updated: 2024-02-20 06:02Details
In the Linux kernel, the following vulnerability has been resolved:
af_unix: fix lockdep positive in sk_diag_dump_icons()
syzbot reported a lockdep splat [1].
Blamed commit hinted about the possible lockdep
violation, and code used unix_state_lock_nested()
in an attempt to silence lockdep.
It is not sufficient, because unix_state_lock_nested()
is already used from unix_state_double_lock().
We need to use a separate subclass.
This patch adds a distinct enumeration to make things
more explicit.
Also use swap() in unix_state_double_lock() as a clean up.
v2: add a missing inline keyword to unix_state_lock_nested()
[1]
WARNING: possible circular locking dependency detected
6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted
syz-executor.1/2542 is trying to acquire lock:
ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863
but task is already holding lock:
ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&u->lock/1){+.+.}-{2:2}:
lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
_raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378
sk_diag_dump_icons net/unix/diag.c:87 [inline]
sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157
sk_diag_dump net/unix/diag.c:196 [inline]
unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220
netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264
__netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370
netlink_dump_start include/linux/netlink.h:338 [inline]
unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319
sock_diag_rcv_msg+0xe3/0x400
netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543
sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_write_iter+0x39a/0x520 net/socket.c:1160
call_write_iter include/linux/fs.h:2085 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0xa74/0xca0 fs/read_write.c:590
ksys_write+0x1a0/0x2c0 fs/read_write.c:643
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
-> #0 (rlock-AF_UNIX){+.+.}-{2:2}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
__lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863
unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x592/0x890 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
__do_sys_sendmmsg net/socket.c:2753 [inline]
__se_sys_sendmmsg net/socket.c:2750 [inline]
__x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
---truncated---
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2024-26624"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: fix lockdep positive in sk_diag_dump_icons()\n\nsyzbot reported a lockdep splat [1].\n\nBlamed commit hinted about the possible lockdep\nviolation, and code used unix_state_lock_nested()\nin an attempt to silence lockdep.\n\nIt is not sufficient, because unix_state_lock_nested()\nis already used from unix_state_double_lock().\n\nWe need to use a separate subclass.\n\nThis patch adds a distinct enumeration to make things\nmore explicit.\n\nAlso use swap() in unix_state_double_lock() as a clean up.\n\nv2: add a missing inline keyword to unix_state_lock_nested()\n\n[1]\nWARNING: possible circular locking dependency detected\n6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted\n\nsyz-executor.1/2542 is trying to acquire lock:\n ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863\n\nbut task is already holding lock:\n ffff88808b5dfe70 (\u0026u-\u003elock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026u-\u003elock/1){+.+.}-{2:2}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378\n sk_diag_dump_icons net/unix/diag.c:87 [inline]\n sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157\n sk_diag_dump net/unix/diag.c:196 [inline]\n unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220\n netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264\n __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:338 [inline]\n unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319\n sock_diag_rcv_msg+0xe3/0x400\n netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543\n sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_write_iter+0x39a/0x520 net/socket.c:1160\n call_write_iter include/linux/fs.h:2085 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xa74/0xca0 fs/read_write.c:590\n ksys_write+0x1a0/0x2c0 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\n-\u003e #0 (rlock-AF_UNIX){+.+.}-{2:2}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162\n skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863\n unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x592/0x890 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724\n __do_sys_sendmmsg net/socket.c:2753 [inline]\n __se_sys_sendmmsg net/socket.c:2750 [inline]\n __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 \n---truncated---",
"id": "GSD-2024-26624",
"modified": "2024-02-20T06:02:29.197709Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2024-26624",
"STATE": "REJECT"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
],
"id": "CVE-2024-26624",
"lastModified": "2024-03-27T14:15:10.163",
"metrics": {},
"published": "2024-03-06T07:15:12.360",
"references": [],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Rejected"
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
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.