Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.

Affected products

Linux
  • <5.8
  • ==6e0bc946cbeec538322820786b5fb5200a2216ab
  • <10f86a2a5c91fc4c4d001960f1c21abe52545ef6
  • ==5.9
  • <18e3ffde1822f0b48b1753bf34aa97ce839df1d8
  • ==db7f8c57dbdd31f7e59f8dc8d1e1b38607a320ef
  • <5.5
  • ==cd4644d904e1d153d516e73e2e127e7a2fe687e1
  • =<7.0.*
  • <5.9
  • ==a7e52f7f675046d9ffc5692d815fa67c82fcdbf5
  • =<*
  • <5.9
  • ==48be3df15aa19c04eadf156c9129293c9a10389f
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: pull headers in qdisc_pkt_len_segs_init()

In the Linux kernel, the following vulnerability has been resolved: net: pull headers in qdisc_pkt_len_segs_init() Most ndo_start_xmit() methods expects headers of gso packets to be already in skb->head. net/core/tso.c users are particularly at risk, because tso_build_hdr() does a memcpy(hdr, skb->data, hdr_len); qdisc_pkt_len_segs_init() already does a dissection of gso packets. Use pskb_may_pull() instead of skb_header_pointer() to make sure drivers do not have to reimplement this. Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.

Affected products

Linux
  • ==3.16
  • <3.16
  • =<7.0.*
  • <9d4f5c68f5ad4ab425f3ce1500c97c9f9743999a
  • =<*
  • <7fb4c19670110f052c04e1ec1d2b953b9f4f57e4
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
s390/bpf: Zero-extend bpf prog return values and kfunc arguments

In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Zero-extend bpf prog return values and kfunc arguments s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too.

Affected products

Linux
  • ==6.3
  • =<6.18.*
  • <834918a77be51419383bf1dda9f02b81ecf26b34
  • <202e42e4aa890172366354b233c42c73107a3f59
  • <6.3
  • =<7.0.*
  • <366b0e05ee24f5ba62bdc7ec1346038258b9a797
  • =<*
  • <44c4f999b03f55debb1a0c5ab5c1796895a1adf8
  • <edc90a12073b9a530064a99945c183dde120cb99
  • =<6.12.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-13037
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Use after free in WebView in Google Chrome on Android …

Use after free in WebView in Google Chrome on Android prior to 149.0.7827.197 allowed a local attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Affected products

Chrome
  • <149.0.7827.197
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nfnetlink_osf: fix out-of-bounds read on option matching

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix out-of-bounds read on option matching In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.

Affected products

Linux
  • =<6.18.*
  • =<7.0.*
  • <edb78a142d2e5948e63647c0646aa7e7886935f0
  • =<6.1.*
  • <70a3f31d25cf2ec9d4ddfa408120171ead955623
  • <21883587593d7c8bb519a79460a0b5bc5ffbdabd
  • ==8316b60582facd4068fb0916c4db2418c21b7174
  • <4.20
  • <5.0
  • ==5.0
  • <1e19a07291bb8682c14c39a64725a3ae54ab8ccc
  • <1c136f2c44a5913646bac85303612fd0825197a0
  • =<5.15.*
  • ==0c1054e0e5fdef2369fb089e94def978bd209e1f
  • <32e50f92c7cf3f4eba29622179a5fcdc2aebab41
  • <f5ca450087c3baf3651055e7a6de92600f827af3
  • =<*
  • <0145548346c4a30981a870a8ca00eac46ba27e85
  • <4.21
  • =<6.12.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership.

Affected products

Linux
  • ==6.9
  • =<6.18.*
  • <91e77840bf13de3add125060cf8b32ca24a52c8c
  • =<7.0.*
  • <d5059e52fd8bc624ec4255c9fa01a266513d126b
  • =<*
  • <6.9
  • <35180c772f5e11e2fa4d80d3dfd50906cb6d9646
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc()

In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc() Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling.

Affected products

Linux
  • <54e97360b44bed6b4399dd3be3d65f392df940fa
  • <da99d0302d3ccccfb13c69e663bf8eae698b9562
  • <6.16
  • =<6.18.*
  • =<7.0.*
  • ==6.16
  • <16dfbc4e95c46dd9c79cb8d550c7f267d4a79b91
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: hisilicon/sec2 - prevent req used-after-free for sec

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec2 - prevent req used-after-free for sec During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx.

Affected products

Linux
  • =<6.18.*
  • <6.17
  • <b375c3c7209cc59e40e97998aa9bc768369cca0e
  • <ad73563f3a1edbfddf2724136c6a15826b354e18
  • =<7.0.*
  • =<*
  • <67b53a660e6bf0da2fa8d8872e897a14d8059eaf
  • ==6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix linked reg delta tracking when src_reg == dst_reg

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix linked reg delta tracking when src_reg == dst_reg Consider the case of rX += rX where src_reg and dst_reg are pointers to the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first modifies the dst_reg in-place, and later in the delta tracking, the subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the post-{add,sub} value instead of the original source. This is problematic since it sets an incorrect delta, which sync_linked_regs() then propagates to linked registers, thus creating a verifier-vs-runtime mismatch. Fix it by just skipping this corner case.

Affected products

Linux
  • <d88e8e4a3b52bd5b2ff3eceba4b29d1b5506d066
  • <6.11
  • =<6.18.*
  • <cc86a8b0a1c54d2bccf6f68cf49b82dea91b84de
  • =<7.0.*
  • <d7f14173c0d5866c3cae759dee560ad1bed10d2e
  • =<*
  • ==6.11
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
um: Fix potential race condition in TLB sync

In the Linux kernel, the following vulnerability has been resolved: um: Fix potential race condition in TLB sync During the TLB sync, we need to traverse and modify the page table, so we should hold the page table lock. Since full SMP support for threads within the same process is still missing, let's disable the split page table lock for simplicity.

Affected products

Linux
  • <6.19
  • =<7.0.*
  • <f21c343ec7419377bff89ab11146c03ae117036f
  • =<*
  • <102331b66bcaf1f41f50b9c4cd5c36e46bafa9f3
  • ==6.19