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, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size

In the Linux kernel, the following vulnerability has been resolved: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __bui ---truncated---

Affected products

Linux
  • <6.0
  • <368d21ae9081c93497b1c8163bed3eddcb2443ff
  • =<6.18.*
  • <d5bd8b4e39cfa8b087448adcd48088065cd629d5
  • =<7.0.*
  • ==6.0
  • =<*
  • <7eb72425c4e3234926502eb262f9d6193ccd572c
  • =<6.12.*
  • <0c22d9511cbde746622f8e4c11aaa63fe76d45f9
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
platform/x86: dell-wmi-sysman: bound enumeration string aggregation

In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: bound enumeration string aggregation populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. [ij: add include]

Affected products

Linux
  • <c5683ca4949a514fbe656c6d0d08c4c126e21db9
  • ==5.11
  • =<5.15.*
  • <7b3dc1f764bf24eb99474a5de8173b0b43a8b071
  • <90b118d264845f7aaf539ac49f7c75f1f29590e2
  • <3c34471c26abc52a37f5ad90949e2e4b8027eb14
  • =<6.18.*
  • =<6.12.*
  • <ba0843c1955864401295f7ba3b420afe19f2266d
  • =<7.0.*
  • <75c738d4f27fa18a2a033de153bd40302bde6a66
  • <5.11
  • =<*
  • <5a04f9a36930792f6d64e28d43609e158d09b665
  • =<6.1.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gfs2: add some missing log locking

In the Linux kernel, the following vulnerability has been resolved: gfs2: add some missing log locking Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush().

Affected products

Linux
  • <3b28eb75afe520972bacc833850c2b30aa0824cd
  • <98e8bf249c790d56de1abc4a5f8bd68035a00921
  • <fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • ==5.7
  • =<7.0.*
  • <ca95342cb1b39062a03c115830286f0a426053d5
  • <f2f225cf505ac016132ded21690f3ba0a080a4e8
  • <49d9be0722da3a4a893ba905720cba1921834ec3
  • =<*
  • <5.7
  • =<6.1.*
  • <bf5fcd9c37c2546beaf7b401d31aefd89017dc3d
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nat: use kfree_rcu to release ops

In the Linux kernel, the following vulnerability has been resolved: netfilter: nat: use kfree_rcu to release ops Florian Westphal says: "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks. However, in v5.14 I added the ability to dump the active netfilter hooks from userspace. This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath. The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though. But once that changes the nat ops structures have to be deferred too." Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook.

Affected products

Linux
  • =<6.18.*
  • <5.14
  • =<7.0.*
  • <32fdd2e38e7435a368d88f5977a7d6585ebc8b0e
  • ==5.14
  • =<*
  • <6eda0d771f94267f73f57c94630aa47e90957915
  • <3c7511f38ab511b791196b13ae48bf4973bf7dfd
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
md: fix array_state=clear sysfs deadlock

In the Linux kernel, the following vulnerability has been resolved: md: fix array_state=clear sysfs deadlock When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned.

Affected products

Linux
  • <6.17
  • =<6.18.*
  • <92ad0ec509ffb188d8f849b63148664df37b4a52
  • =<7.0.*
  • <2aa72276fab9851dbd59c2daeb4b590c5a113908
  • =<*
  • <62c44566da7493ee48ef17e8507bb798338a07cb
  • ==6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on

In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur.

Affected products

Linux
  • <010983063a806720b45778d191335f8ea864fea3
  • =<6.18.*
  • <b059a41bdd5b202b2b9d7708403fb43c69689e53
  • ==70212c2300971506e986d95000d2745529cac9d7
  • <ce899f9c019591b73ef84b9afa332ed53beece25
  • <6.13
  • ==6.13
  • =<7.0.*
  • =<*
  • <34b3eef48d980cd37b876e128bbf314f69fb5d70
  • <6.12.91
  • <6.12
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix abuse of kprobe_write_ctx via freplace

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix abuse of kprobe_write_ctx via freplace uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC("?kprobe") int kprobe(struct pt_regs *regs) { return 0; } SEC("?freplace") int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.

Affected products

Linux
  • <9836cadbd96c7e0dbb0018fa60e7872dd31ac4f8
  • =<6.18.*
  • <b312cf41b9e43f442613053f6cad39898e1baf96
  • =<7.0.*
  • ==6.18
  • =<*
  • <611fe4b79af72d00d80f2223354284447daafae9
  • <6.18
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-13021
4.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Inappropriate implementation in DeviceBoundSessionCredentials in Google Chrome prior to 149.0.7827.197 …

Inappropriate implementation in DeviceBoundSessionCredentials in Google Chrome prior to 149.0.7827.197 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: High)

Affected products

Chrome
  • <149.0.7827.197
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: bcmgenet: fix leaking free_bds

In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix leaking free_bds While reclaiming the tx queue we fast forward the write pointer to drop any data in flight. These dropped frames are not added back to the pool of free bds. We also need to tell the netdev that we are dropping said data.

Affected products

Linux
  • <3f3168300efb839028328d720ab3962f91d6a0d0
  • <6.15
  • <3c3abbcfa05bad17965498ff7cc94c2418fa94b3
  • =<6.18.*
  • <ac4a29c331ecb5b10240c44247a8e010c95bc15b
  • <52b9f80993698138b90e5ca3a72550a2501f2a96
  • =<7.0.*
  • <150d06aae1839a6564ab200ef0e7291c3528bbb0
  • ==6.15
  • =<*
  • <25ff3a3e47ea635ec08dc93e84dd2bfe15abfebb
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 1 day ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
block: fix zones_cond memory leak on zone revalidation error paths

In the Linux kernel, the following vulnerability has been resolved: block: fix zones_cond memory leak on zone revalidation error paths When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it.

Affected products

Linux
  • <29153d128384fa7c48a8ca8d34094b1cbe2d5bdc
  • <2a2f520fda824b5a25c93f2249578ea150c24e06
  • =<7.0.*
  • <6.19
  • =<*
  • ==6.19