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 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
btrfs: fix deadlock between reflink and transaction commit when using flushoncommit

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between reflink and transaction commit when using flushoncommit When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node. The deadlock happens like this: 1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page(); 2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc; 3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero); 4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A. Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: <TASK> context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid: ---truncated---

Affected products

Linux
  • ==5.7
  • <6f0f9c0a368aa1fe078109091322d3b0632d9380
  • =<*
  • <9a24f0000876b8755cf21972b41632f4d6f3dafb
  • =<6.18.*
  • <73be4a08306bb84f4d5d16f62cb80e1543109ffa
  • =<6.12.*
  • <b48c980b6a7e409050bb3067165db31cc6205e3e
  • =<7.0.*
  • <5.7
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • ==a7e52f7f675046d9ffc5692d815fa67c82fcdbf5
  • ==6e0bc946cbeec538322820786b5fb5200a2216ab
  • <18e3ffde1822f0b48b1753bf34aa97ce839df1d8
  • <5.9
  • ==cd4644d904e1d153d516e73e2e127e7a2fe687e1
  • =<*
  • <10f86a2a5c91fc4c4d001960f1c21abe52545ef6
  • ==48be3df15aa19c04eadf156c9129293c9a10389f
  • <5.5
  • ==5.9
  • <5.8
  • <5.9
  • =<7.0.*
  • ==db7f8c57dbdd31f7e59f8dc8d1e1b38607a320ef
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • <9d4f5c68f5ad4ab425f3ce1500c97c9f9743999a
  • <3.16
  • =<*
  • <7fb4c19670110f052c04e1ec1d2b953b9f4f57e4
  • ==3.16
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • =<*
  • <366b0e05ee24f5ba62bdc7ec1346038258b9a797
  • <44c4f999b03f55debb1a0c5ab5c1796895a1adf8
  • <edc90a12073b9a530064a99945c183dde120cb99
  • ==6.3
  • =<6.18.*
  • <202e42e4aa890172366354b233c42c73107a3f59
  • =<6.6.*
  • =<6.12.*
  • =<7.0.*
  • <834918a77be51419383bf1dda9f02b81ecf26b34
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 2 months 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 2 months 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
  • ==0c1054e0e5fdef2369fb089e94def978bd209e1f
  • =<*
  • =<5.10.*
  • =<6.12.*
  • <32e50f92c7cf3f4eba29622179a5fcdc2aebab41
  • =<6.1.*
  • <edb78a142d2e5948e63647c0646aa7e7886935f0
  • =<6.6.*
  • <5.0
  • ==8316b60582facd4068fb0916c4db2418c21b7174
  • <1c136f2c44a5913646bac85303612fd0825197a0
  • <f5ca450087c3baf3651055e7a6de92600f827af3
  • <1e19a07291bb8682c14c39a64725a3ae54ab8ccc
  • <0145548346c4a30981a870a8ca00eac46ba27e85
  • <70a3f31d25cf2ec9d4ddfa408120171ead955623
  • <21883587593d7c8bb519a79460a0b5bc5ffbdabd
  • <4.20
  • =<5.15.*
  • <4.21
  • =<6.18.*
  • ==5.0
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • <91e77840bf13de3add125060cf8b32ca24a52c8c
  • =<*
  • <6.9
  • <d5059e52fd8bc624ec4255c9fa01a266513d126b
  • <35180c772f5e11e2fa4d80d3dfd50906cb6d9646
  • =<6.18.*
  • ==6.9
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • <da99d0302d3ccccfb13c69e663bf8eae698b9562
  • =<*
  • =<6.18.*
  • <16dfbc4e95c46dd9c79cb8d550c7f267d4a79b91
  • <6.16
  • =<7.0.*
  • <54e97360b44bed6b4399dd3be3d65f392df940fa
  • ==6.16
Dismissed
(max. allowed matches exceeded)
created 2 months 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.*
  • <b375c3c7209cc59e40e97998aa9bc768369cca0e
  • =<*
  • <67b53a660e6bf0da2fa8d8872e897a14d8059eaf
  • <ad73563f3a1edbfddf2724136c6a15826b354e18
  • ==6.17
  • =<7.0.*
  • <6.17
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • <cc86a8b0a1c54d2bccf6f68cf49b82dea91b84de
  • ==6.11
  • <d7f14173c0d5866c3cae759dee560ad1bed10d2e
  • =<7.0.*
  • =<6.18.*
  • <d88e8e4a3b52bd5b2ff3eceba4b29d1b5506d066
  • =<*
  • <6.11