CVE-2026-53034 (GCVE-0-2026-53034)
Vulnerability from cvelistv5 – Published: 2026-06-24 16:29 – Updated: 2026-06-24 16:29
VLAI
Title
bpf, sockmap: Fix af_unix null-ptr-deref in proto update
Summary
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix af_unix null-ptr-deref in proto update
unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state,
TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).
sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that
socket is properly set up, which would include having a defined peer. IOW,
there's a window when unix_stream_bpf_update_proto() can be called on
socket which still has unix_peer(sk) == NULL.
CPU0 bpf CPU1 connect
-------- ------------
WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)
sock_map_sk_state_allowed(sk)
...
sk_pair = unix_peer(sk)
sock_hold(sk_pair)
sock_hold(newsk)
smp_mb__after_atomic()
unix_peer(sk) = newsk
BUG: kernel NULL pointer dereference, address: 0000000000000080
RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0
Call Trace:
sock_map_link+0x564/0x8b0
sock_map_update_common+0x6e/0x340
sock_map_update_elem_sys+0x17d/0x240
__sys_bpf+0x26db/0x3250
__x64_sys_bpf+0x21/0x30
do_syscall_64+0x6b/0x3a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Initial idea was to move peer assignment _before_ the sk_state update[1],
but that involved an additional memory barrier, and changing the hot path
was rejected.
Then a NULL check during proto update in unix_stream_bpf_update_proto() was
considered[2], but the follow-up discussion[3] focused on the root cause,
i.e. sockmap update taking a wrong lock. Or, more specifically, missing
unix_state_lock()[4].
In the end it was concluded that teaching sockmap about the af_unix locking
would be unnecessarily complex[5].
Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT
are allowed to update sockmaps, sock_map_update_elem() taking the unix
lock, as it is currently implemented in unix_state_lock():
spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken
in a process context, followed by a softirq-context TC BPF program
attempting to take the same spinlock -- deadlock[6].
This way we circled back to the peer check idea[2].
[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/
[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/
[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/
[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/
[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/
[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/
Summary of scenarios where af_unix/stream connect() may race a sockmap
update:
1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()
Implemented NULL check is sufficient. Once assigned, socket peer won't
be released until socket fd is released. And that's not an issue because
sock_map_update_elem_sys() bumps fd refcnf.
2. connect() vs BPF program doing update
Update restricted per verifier.c:may_update_sockmap() to
BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER
BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)
BPF_PROG_TYPE_SOCKET_FILTER
BPF_PROG_TYPE_SCHED_CLS
BPF_PROG_TYPE_SCHED_ACT
BPF_PROG_TYPE_XDP
BPF_PROG_TYPE_SK_REUSEPORT
BPF_PROG_TYPE_FLOW_DISSECTOR
BPF_PROG_TYPE_SK_LOOKUP
Plus one more race to consider:
CPU0 bpf CPU1 connect
-------- ------------
WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)
sock_map_sk_state_allowed(sk)
sock_hold(newsk)
smp_mb__after_atomic()
---truncated---
Severity
No CVSS data available.
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
c63829182c37c2d6d0608976d15fa61ebebe9e6b , < 75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4
(git)
Affected: c63829182c37c2d6d0608976d15fa61ebebe9e6b , < a94d3dd78ee8b63e6b8ad629081c952c93ee5a10 (git) Affected: c63829182c37c2d6d0608976d15fa61ebebe9e6b , < 4913c94a3adcdbb64c552110c0c243cb1fdbb317 (git) Affected: c63829182c37c2d6d0608976d15fa61ebebe9e6b , < 041eb6348d73ee5e15fc8161f1eac5a6e8289ca0 (git) Affected: c63829182c37c2d6d0608976d15fa61ebebe9e6b , < 37bfcd164161b47d00b1c3bd20adc816a6977ce0 (git) Affected: c63829182c37c2d6d0608976d15fa61ebebe9e6b , < dca38b7734d2ea00af4818ff3ae836fab33d5d5a (git) |
|
| Linux | Linux |
Affected:
5.15
Unaffected: 0 , < 5.15 (semver) Unaffected: 6.1.175 , ≤ 6.1.* (semver) Unaffected: 6.6.141 , ≤ 6.6.* (semver) Unaffected: 6.12.91 , ≤ 6.12.* (semver) Unaffected: 6.18.33 , ≤ 6.18.* (semver) Unaffected: 7.0.10 , ≤ 7.0.* (semver) Unaffected: 7.1 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/unix/unix_bpf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
},
{
"lessThan": "a94d3dd78ee8b63e6b8ad629081c952c93ee5a10",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
},
{
"lessThan": "4913c94a3adcdbb64c552110c0c243cb1fdbb317",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
},
{
"lessThan": "041eb6348d73ee5e15fc8161f1eac5a6e8289ca0",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
},
{
"lessThan": "37bfcd164161b47d00b1c3bd20adc816a6977ce0",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
},
{
"lessThan": "dca38b7734d2ea00af4818ff3ae836fab33d5d5a",
"status": "affected",
"version": "c63829182c37c2d6d0608976d15fa61ebebe9e6b",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/unix/unix_bpf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.15"
},
{
"lessThan": "5.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.141",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.33",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.141",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.91",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.33",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0.10",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.1",
"versionStartIncluding": "5.15",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix af_unix null-ptr-deref in proto update\n\nunix_stream_connect() sets sk_state (`WRITE_ONCE(sk-\u003esk_state,\nTCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).\nsk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that\nsocket is properly set up, which would include having a defined peer. IOW,\nthere\u0027s a window when unix_stream_bpf_update_proto() can be called on\nsocket which still has unix_peer(sk) == NULL.\n\n CPU0 bpf CPU1 connect\n -------- ------------\n\n WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\nsock_map_sk_state_allowed(sk)\n...\nsk_pair = unix_peer(sk)\nsock_hold(sk_pair)\n sock_hold(newsk)\n smp_mb__after_atomic()\n unix_peer(sk) = newsk\n\nBUG: kernel NULL pointer dereference, address: 0000000000000080\nRIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0\nCall Trace:\n sock_map_link+0x564/0x8b0\n sock_map_update_common+0x6e/0x340\n sock_map_update_elem_sys+0x17d/0x240\n __sys_bpf+0x26db/0x3250\n __x64_sys_bpf+0x21/0x30\n do_syscall_64+0x6b/0x3a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInitial idea was to move peer assignment _before_ the sk_state update[1],\nbut that involved an additional memory barrier, and changing the hot path\nwas rejected.\nThen a NULL check during proto update in unix_stream_bpf_update_proto() was\nconsidered[2], but the follow-up discussion[3] focused on the root cause,\ni.e. sockmap update taking a wrong lock. Or, more specifically, missing\nunix_state_lock()[4].\nIn the end it was concluded that teaching sockmap about the af_unix locking\nwould be unnecessarily complex[5].\nComplexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT\nare allowed to update sockmaps, sock_map_update_elem() taking the unix\nlock, as it is currently implemented in unix_state_lock():\nspin_lock(\u0026unix_sk(s)-\u003elock), would be problematic. unix_state_lock() taken\nin a process context, followed by a softirq-context TC BPF program\nattempting to take the same spinlock -- deadlock[6].\nThis way we circled back to the peer check idea[2].\n\n[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/\n[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/\n[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/\n[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/\n[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/\n[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/\n\nSummary of scenarios where af_unix/stream connect() may race a sockmap\nupdate:\n\n1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()\n\n Implemented NULL check is sufficient. Once assigned, socket peer won\u0027t\n be released until socket fd is released. And that\u0027s not an issue because\n sock_map_update_elem_sys() bumps fd refcnf.\n\n2. connect() vs BPF program doing update\n\n Update restricted per verifier.c:may_update_sockmap() to\n\n BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER\n BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)\n BPF_PROG_TYPE_SOCKET_FILTER\n BPF_PROG_TYPE_SCHED_CLS\n BPF_PROG_TYPE_SCHED_ACT\n BPF_PROG_TYPE_XDP\n BPF_PROG_TYPE_SK_REUSEPORT\n BPF_PROG_TYPE_FLOW_DISSECTOR\n BPF_PROG_TYPE_SK_LOOKUP\n\n Plus one more race to consider:\n\n CPU0 bpf CPU1 connect\n -------- ------------\n\n WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\n sock_map_sk_state_allowed(sk)\n sock_hold(newsk)\n smp_mb__after_atomic()\n \n---truncated---"
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T16:29:41.676Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4"
},
{
"url": "https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10"
},
{
"url": "https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317"
},
{
"url": "https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0"
},
{
"url": "https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0"
},
{
"url": "https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a"
}
],
"title": "bpf, sockmap: Fix af_unix null-ptr-deref in proto update",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-53034",
"datePublished": "2026-06-24T16:29:41.676Z",
"dateReserved": "2026-06-09T07:44:35.380Z",
"dateUpdated": "2026-06-24T16:29:41.676Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-53034",
"date": "2026-07-06",
"epss": "0.0018",
"percentile": "0.07767"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2026-53034\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-06-24T17:17:14.843\",\"lastModified\":\"2026-06-24T17:17:14.843\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf, sockmap: Fix af_unix null-ptr-deref in proto update\\n\\nunix_stream_connect() sets sk_state (`WRITE_ONCE(sk-\u003esk_state,\\nTCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).\\nsk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that\\nsocket is properly set up, which would include having a defined peer. IOW,\\nthere\u0027s a window when unix_stream_bpf_update_proto() can be called on\\nsocket which still has unix_peer(sk) == NULL.\\n\\n CPU0 bpf CPU1 connect\\n -------- ------------\\n\\n WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\\nsock_map_sk_state_allowed(sk)\\n...\\nsk_pair = unix_peer(sk)\\nsock_hold(sk_pair)\\n sock_hold(newsk)\\n smp_mb__after_atomic()\\n unix_peer(sk) = newsk\\n\\nBUG: kernel NULL pointer dereference, address: 0000000000000080\\nRIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0\\nCall Trace:\\n sock_map_link+0x564/0x8b0\\n sock_map_update_common+0x6e/0x340\\n sock_map_update_elem_sys+0x17d/0x240\\n __sys_bpf+0x26db/0x3250\\n __x64_sys_bpf+0x21/0x30\\n do_syscall_64+0x6b/0x3a0\\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\\n\\nInitial idea was to move peer assignment _before_ the sk_state update[1],\\nbut that involved an additional memory barrier, and changing the hot path\\nwas rejected.\\nThen a NULL check during proto update in unix_stream_bpf_update_proto() was\\nconsidered[2], but the follow-up discussion[3] focused on the root cause,\\ni.e. sockmap update taking a wrong lock. Or, more specifically, missing\\nunix_state_lock()[4].\\nIn the end it was concluded that teaching sockmap about the af_unix locking\\nwould be unnecessarily complex[5].\\nComplexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT\\nare allowed to update sockmaps, sock_map_update_elem() taking the unix\\nlock, as it is currently implemented in unix_state_lock():\\nspin_lock(\u0026unix_sk(s)-\u003elock), would be problematic. unix_state_lock() taken\\nin a process context, followed by a softirq-context TC BPF program\\nattempting to take the same spinlock -- deadlock[6].\\nThis way we circled back to the peer check idea[2].\\n\\n[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/\\n[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/\\n[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/\\n[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/\\n[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/\\n[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/\\n\\nSummary of scenarios where af_unix/stream connect() may race a sockmap\\nupdate:\\n\\n1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()\\n\\n Implemented NULL check is sufficient. Once assigned, socket peer won\u0027t\\n be released until socket fd is released. And that\u0027s not an issue because\\n sock_map_update_elem_sys() bumps fd refcnf.\\n\\n2. connect() vs BPF program doing update\\n\\n Update restricted per verifier.c:may_update_sockmap() to\\n\\n BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER\\n BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)\\n BPF_PROG_TYPE_SOCKET_FILTER\\n BPF_PROG_TYPE_SCHED_CLS\\n BPF_PROG_TYPE_SCHED_ACT\\n BPF_PROG_TYPE_XDP\\n BPF_PROG_TYPE_SK_REUSEPORT\\n BPF_PROG_TYPE_FLOW_DISSECTOR\\n BPF_PROG_TYPE_SK_LOOKUP\\n\\n Plus one more race to consider:\\n\\n CPU0 bpf CPU1 connect\\n -------- ------------\\n\\n WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\\n sock_map_sk_state_allowed(sk)\\n sock_hold(newsk)\\n smp_mb__after_atomic()\\n \\n---truncated---\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"net/unix/unix_bpf.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"a94d3dd78ee8b63e6b8ad629081c952c93ee5a10\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"4913c94a3adcdbb64c552110c0c243cb1fdbb317\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"041eb6348d73ee5e15fc8161f1eac5a6e8289ca0\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"37bfcd164161b47d00b1c3bd20adc816a6977ce0\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c63829182c37c2d6d0608976d15fa61ebebe9e6b\",\"lessThan\":\"dca38b7734d2ea00af4818ff3ae836fab33d5d5a\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"net/unix/unix_bpf.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.15\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.15\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.175\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.141\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.91\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.33\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.0.10\",\"lessThanOrEqual\":\"7.0.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.1\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
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.
Loading…
Loading…