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, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path

In the Linux kernel, the following vulnerability has been resolved: landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path LANDLOCK_SCOPE_SIGNAL must prevent a sandboxed process from signaling processes outside its Landlock domain. It can be bypassed through the asynchronous SIGIO delivery path. A sandboxed process that owns any file or socket can arm it with fcntl(fd, F_SETOWN, -pgid), fcntl(fd, F_SETSIG, SIGKILL) and O_ASYNC, so that an I/O event makes the kernel deliver the chosen signal to the whole process group. As the head of its process group's task list (the default position right after fork()) that group can also hold the non-sandboxed process that launched it, e.g. a supervisor or a security monitor. The sandbox can thus kill or signal the processes LANDLOCK_SCOPE_SIGNAL is meant to protect from it. The scope is enforced in hook_file_send_sigiotask() against the Landlock domain recorded at F_SETOWN time, not the live domain of the sender. control_current_fowner() decides whether to record that domain and skips recording it when the fowner target is in the caller's thread group, which is safe only for a single-task target (PIDTYPE_PID, PIDTYPE_TGID). For a process group (PIDTYPE_PGID) pid_task() returns only one member; recording is skipped whenever that member shares the caller's thread group, and hook_file_send_sigiotask() then lets the signal fan out to the whole group unchecked. Record the domain for every non single-process target so the scope is enforced against each group member at delivery time. That recording is necessary but not sufficient on its own: the kernel signals a process group through its members' thread-group leaders, and the leader of the registrant's own process can carry a different Landlock domain than the sibling thread that armed the owner. domain_is_scoped() would then deny that leader, even though commit 18eb75f3af40 ("landlock: Always allow signals between threads of the same process") requires same-process delivery to be allowed. hook_task_kill() avoids this by evaluating same_thread_group() live, per recipient; the SIGIO path instead delegates the whole decision to a single registration-time check, which a process-group fan-out cannot honor. So also record the registrant's thread group next to its domain and exempt it at delivery: hook_file_send_sigiotask() allows the signal whenever the recipient belongs to the registrant's own process, restoring the same-process guarantee while keeping out-of-domain group members blocked. The direct kill() path (hook_task_kill) already evaluates the live domain and is unaffected. [mic: Check pid_type earlier and improve comment, fix commit message, fix comment formatting]

Affected products

Linux
  • <6.12.101
  • <1f18aac2637220b5847d073447498e81ddca10b2
  • <7a92e9fd1d496a610b40e0c4253fd54e7496f5ab
  • =<*
  • <6.15
  • ==6.15
  • <6.15
  • <6.14
  • =<6.12.*
  • ==6861348d863c0eaa4af67492d640a9644a829c59
  • =<6.18.*
  • =<7.1.*
  • <4b80320ca7ed03d6e683f95b6066565dc97b9f92
  • ==0906a9685d7057aea982e970da3e1cf3e5aca68b
  • <04916f7dc6d37cd478b06c86398c34a6963ac8c9
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs: free volume-wide resources on fill_super failure

In the Linux kernel, the following vulnerability has been resolved: ntfs: free volume-wide resources on fill_super failure ntfs_fill_super()'s err_out_now path frees only the volume struct via kfree(vol), leaving several vol-owned allocations behind on every mount failure: - vol->nls_map, loaded by ntfs_init_fs_context() via load_nls_default() (or replaced by an explicit nls= option in ntfs_parse_param()), is never unload_nls()'d. - vol->volume_label, allocated by load_system_files() through ntfs_ucstonls() once the $Volume name attribute has been parsed, is not released by load_system_files()'s own error labels nor by the fill_super() inline cleanup that only runs on d_make_root() failure. Any later failure inside load_system_files() leaks it. - vol->lcn_empty_bits_per_page was kvfree()'d in unl_upcase_iput_tmp_ino_err_out_now without clearing the pointer, so it could not be folded into a single common cleanup. Because the failure paths never call ntfs_volume_free() and never reach the d_make_root() inline cleanup block (it sits above the label and is jumped over by the load_system_files() / kvmalloc failure gotos), these resources accumulate per failed mount attempt with no chance of recovery short of unloading the module. This is a silent leak: the inodes loaded prior to failure remain hashed but generic_shutdown_super() skips evict_inodes() when sb->s_root is unset, so no CHECK_DATA_CORRUPTION warning is emitted either. Move the per-volume frees down to err_out_now and drop the lcn_empty_bits_per_page kvfree() from the upper label so the cleanup is performed exactly once on every failure path. Using unconditional kvfree() / kfree() / unload_nls() is safe because they all accept NULL and the upper labels that previously freed nls_map (the d_make_root() inline cleanup) already clear the pointer.

Affected products

Linux
  • <aca3d383a23cb7f3a2849c09fda3974f1838d941
  • =<*
  • <7.1.5
  • =<7.1.*
  • <a9523a7d3b24b3a6b25ec1eb668ee6618cacf05e
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
md/raid1,raid10: fix deadlock in read error recovery path

In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: fix deadlock in read error recovery path raid1d and raid10d may resubmit a split md cloned bio while handling a read error. In this case, resubmitting the bio can lead to a deadlock if the array is suspended before md_handle_request() acquires an active_io reference via percpu_ref_tryget_live(). Since the cloned bio already holds an active_io reference, trying to acquire another reference via percpu_ref_tryget_live() can lead to a deadlock while the array is suspended. Fix this by using percpu_ref_get() for md cloned bios.

Affected products

Linux
  • <6.6
  • <38777f014c37972868f1733a651c85288bb8a757
  • ==6.6
  • =<*
  • =<7.1.*
  • <7b15c24f805339a585cfe7d72f446b7e88b9bcc0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ASoC: amd: acp-sdw-sof: Bound DAI link iteration

In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp-sdw-sof: Bound DAI link iteration create_sdw_dailinks() walks sof_dais until it finds an entry with initialised cleared, but sof_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array.

Affected products

Linux
  • ==6.12
  • <86a64c049873fe4d4a6a378e27a333ab5631c4b2
  • <0a5ff4000dd7a390139dd7823fef1de4963e490a
  • =<*
  • <9e82497138abea7d5c6e65015663d907fbcbf6b4
  • <4d992e63f52d58f52b724606c60ae7b37a1c582f
  • <6.12
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nft_set_pipapo: don't leak bad clone into future transaction

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: don't leak bad clone into future transaction On memory allocation failure the cloned nft_pipapo_match can enter a bad state: - some fields can have their lookup tables resized while others did not - bits might have been toggled - scratch map can be undersized which also means m->bsize_max can be lower than what is required This means that the next insertion in the same batch can trigger out-of-bounds writes. Furthermore, a failure in the first can result in the bad clone to leak into the next transaction because the abort callback is never executed in this case (the upper layer saw an error and no attempt to allocate a transactional request was made). Record a state for the nft_pipapo_match structure: - NEW (pristine clone) - MOD (modified clone with good state) - ERR (potentially bogus content) Then make it so that deletes and insertions fail when the clone entered ERR state. In case the very first insert attempt results in an error, free the clone right away.

Affected products

Linux
  • <610e3b73efaec3dd81a95dcda2421ad7d9795bd0
  • =<6.6.*
  • <e74f9680e1b64872a51cc7b5bda1edaaa08aa51f
  • =<*
  • <5.6
  • =<6.18.*
  • =<6.12.*
  • <02b6b0e892aea582590671796fd6eff5b93ea93f
  • <47e65eff50691f0a5b79d325e28d83ec1da43bcf
  • =<7.1.*
  • ==5.6
  • <047e813324eac2ac60cddfb58bcdbd0144eadb09
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()

In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.

Affected products

Linux
  • <656ff69ef235699035e57d9e1ae417e62a38aa7f
  • <5f246b96ab47523ec9b8ea870b5c567a3cb1eb1c
  • ==2.6.25
  • <58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8
  • <c312b750bb5ac3348cfc85dab25e90937bd4d251
  • <2.6.25
  • =<6.6.*
  • =<*
  • <136de17f38630307991c59aa7080012a99451783
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
btrfs: zoned: fix deadlock between metadata writeback and transaction commit

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() <blocks on zoned_meta_io_lock, btrfs_zone_finish() held by Task A> do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() <blocks waiting for commit of transaction T, done by Task B> The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.

Affected products

Linux
  • <75859a7cd77cd2ddaddbcb963e3fcd34738953af
  • <6.6
  • <18577e77c2c8adaadf1f7c6e9bcd1c0b14e5dcdd
  • <6.6
  • <1ebe51c29fa9755d5b2fea28727c051117907cf8
  • <deddd28fd83c264ee2ff5cd6b34449a9f1be6112
  • ==6.6
  • =<6.6.*
  • =<*
  • <c3320873e0c04ce7b746fc8fe948f07bbbbdec33
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • ==fca3a1cd3ba47f1815e0c0fcdc9aafaf02ee0a75
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
md/raid1: fix writes_pending and barrier reference leaks on write failures

In the Linux kernel, the following vulnerability has been resolved: md/raid1: fix writes_pending and barrier reference leaks on write failures raid1_make_request() acquires a writes_pending reference with md_write_start() before calling raid1_write_request(). Several failure paths in raid1_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid1_write_request() return a status indicating whether the write request was successfully queued. This allows raid1_make_request() to call md_write_end() when raid1_write_request() fails. Additionally, if wait_blocked_rdev() fails after wait_barrier() succeeds, the associated barrier reference is not released. Call allow_barrier() before returning from that path to keep the barrier accounting balanced.

Affected products

Linux
  • <bffbbfcbd9393e315a7a4286dcd70e875265db9a
  • <8e065a1602511282fc0da2dc89445e0eb71a681c
  • <5.17
  • =<*
  • ==5.17
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"

In the Linux kernel, the following vulnerability has been resolved: x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN" Revert 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"). Section 8.8 of the SNP spec says: Before invoking SNP_INIT_EX with INIT_RMP set to 1, software must ensure that no CPUs contain dirty cache lines for the memory containing the RMP. Cachelines can be moved from cache to cache in a dirty state. The wbinvd_on_all_cpus() before SNP_INIT_EX flushes the caches for each CPU, but if the IPIs for WBINVD race with this dirty cacheline movement, it is possible that they may not get flushed, violating the firmware requirement. Doing wbinvd_on_all_cpus() before setting SNPEn is safer since the RMP table is not yet in use. [ Heroically bisected by Srikanth. ] [ bp: Massage commit message. ]

Affected products

Linux
  • <e5158ff53fdff9c229bf13aa5f75eb17cdcfcd2d
  • =<*
  • <7.1
  • ==7.1
  • =<7.1.*
  • <4c2509f3b79756679a02bea649c6a7501b58f52c
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication

In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.

Affected products

Linux
  • <df2187acfca6c6cca372c5d35f42394d9c270b09
  • =<5.10.*
  • <64228dfc4247aca178c01e5a37af7d8dcc7a6089
  • <f987efff29a5fe45320ea5991c9d5cb98b676953
  • <4.11
  • =<6.6.*
  • =<*
  • <3cf92b44c4fb88a5e8de8733a4494c0956606bca
  • <f03782f7f41f2afee5076a1ef08ced5649218771
  • ==4.11
  • =<6.12.*
  • =<6.18.*
  • <0907c06dccae9e3c8d5a68eb9014beec73a36e79
  • <22b0b8572a64362531dd0ed499b75e16282aeb2b
  • =<7.1.*
  • =<5.15.*
  • <23d210877968657bd07e1a517e0b516db20a1d80
  • =<6.1.*