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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI The MIPI DSI and CSI domains share control bits for clock and reset, which can lead to incorrect behavior if one domain disables the shared resource while the other is still active. To fix the issue, introduce a shared MIPI PHY power domain to own the common resources and make DSI and CSI its subdomains. This ensures the shared bits are properly managed and not disabled while still in use.

Affected products

Linux
  • <99611233f8cda833169fa6487d5dacdf189e5cb0
  • <6.1
  • ==6.1
  • =<*
  • =<6.18.*
  • =<7.1.*
  • <4ba6d7166750d0b810c6cfc0b1df7585f513b48c
  • <4fd5b33faf092ef2d09f730a7d9e49f9e976ac67
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ext2: fix ignored return value of generic_write_sync()

In the Linux kernel, the following vulnerability has been resolved: ext2: fix ignored return value of generic_write_sync() Fix ext2_dio_write_iter() to propagate the error returned by generic_write_sync() instead of silently discarding it, which could cause write(2) to return success to userspace on O_SYNC/O_DSYNC files even when the sync failed. The correct pattern, already used in ext2_dax_write_iter() in the same file and in ext4, xfs, f2fs among others, is: if (ret > 0) ret = generic_write_sync(iocb, ret); Found by Linux Verification Center (linuxtesting.org) with SVACE. [JK: Reflect also filemap_write_and_wait() return value]

Affected products

Linux
  • ==6.5
  • <a4659be0bc7cb1856ffb15b67f903229ae8891ec
  • <6.5
  • =<6.6.*
  • =<*
  • <8990dbb7065b0b002b1e58b9091a5b61f5e94dbe
  • <b6bc07e49a5fbb335f56eb90cd63dec6584c77d3
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <8d70b3973020e59845c0bdad90e0b9c2295fd493
  • <ffa974b2f50ad8b911b9066d7aed84ad0afabcdb
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
apparmor: check label build before no_new_privs test

In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.

Affected products

Linux
  • <ec926b2a351eeeb31e6c9aee02e0c32f94b5588f
  • <a58cafd38b46fb1a2220e2fbbcfe291ea75fa147
  • =<5.10.*
  • <b7c45c05a396a017c49ac7949de240a0dfc0ac4e
  • =<*
  • ==4.13
  • <d82160132345688a09cbaa648cfdd16bb32e8ea2
  • =<6.6.*
  • =<6.18.*
  • =<6.12.*
  • <d84bb195d208adbf77f012ca2a96e11163f6def1
  • <a29f06db44b4c94597ded58f639eed3e21781ac3
  • =<7.1.*
  • =<5.15.*
  • =<6.1.*
  • <31cb109db5e6322ed22304fd5c0dedbaa438d6d3
  • <4.13
  • <cfc224866530a6842b6c2d2d30ef6a9b0e64bb9c
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipvs: fix more places with wrong ipv6 transport offsets

In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.

Affected products

Linux
  • ==2.6.28
  • <613ce63711b8d431bba90781f133c39a21684f87
  • =<5.10.*
  • <905d7a363ade96a19f214815361e11981142c547
  • =<5.15.*
  • <d4ec18f48ce78a3bf7c999ac908691007375fe99
  • =<6.6.*
  • =<*
  • <2.6.28
  • <7350eb7ead172ae8024897d4b0f2e15c5318279c
  • <a3f0d5b605cd5da5c95279969fb8cea4e55cee5b
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <b3fe4cbd583895987935a9bdad01c8f9d3a02310
  • <3a9dc9b55b53d94613a587604b77d3b20024090c
  • <95d4511d81b2b37e5d2bdde5d912e48243eae517
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mtd: mchp23k256: use SPI match data for chip caps

In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.

Affected products

Linux
  • =<6.6.*
  • ==4.13
  • =<*
  • <7c0a3a73dccc9a3fc701f6be762449f18d0ca0fc
  • <dbe2254d1da99c986f9a3392471fc5eaa3229647
  • <09e044192a42f716215fbd1a100ee87fa57426aa
  • =<6.18.*
  • =<6.12.*
  • <d322e40f4edf92bf0ca329e5aa4ae1c0316feb38
  • =<7.1.*
  • <2e179b028da9fd628a09286a2c9df4fa076b2cc9
  • =<5.15.*
  • <a0c38083623c8b210a5b87fd34bebd05aa935ae8
  • <04ebd3766861f219325852c9598e0f0281cb3636
  • <4.13
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: access unicast_ttvn skb->data only after skb realloc

In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.

Affected products

Linux
  • <ed90eb5c68420cdfe67ec1f773324198d2ef6f50
  • =<5.10.*
  • <7141990add3f75436f2933cb310654cad3b1e3e9
  • <aa9558af859934f24717d4bab97d61004f91a736
  • ==3.13
  • <9c2c05629e46c1fd43931506d41c56a885a98eb4
  • <7b162b36de750565404cd3b98315706622c6974f
  • =<6.6.*
  • =<*
  • <b8afcf799b2cc92c41beebd029e53ed18960184a
  • =<6.18.*
  • =<6.12.*
  • <3.13
  • =<5.15.*
  • <9a7b7248798123efbd5fafe58461d57c7cc718af
  • =<7.1.*
  • <979175834a699ccc3c4c0b0ba60ecae0f135a587
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
afs: Fix reinitialisation of the inode, in particular ->lock_work

In the Linux kernel, the following vulnerability has been resolved: afs: Fix reinitialisation of the inode, in particular ->lock_work It seems that initalising afs_vnode::lock_work a single time in the slab's init function isn't sufficient for work_structs. This results in the DEBUG_OBJECTS debugging stuff producing a warning occasionally when running the generic/131 xfstest: ODEBUG: activate not available (active state 0) object: 0000000016d8760f object type: work_struct hint: afs_lock_work+0x0/0x220 WARNING: lib/debugobjects.c:629 at debug_print_object+0x4b/0x90, CPU#3: locktest/7695 ... CPU: 3 UID: 0 PID: 7695 Comm: locktest Tainted: G S 7.1.0-build3+ #2771 PREEMPT ... RIP: 0010:debug_print_object+0x65/0x90 ... Call Trace: <TASK> ? __pfx_afs_lock_work+0x10/0x10 debug_object_activate+0x122/0x170 insert_work+0x25/0x60 __queue_work+0x2e0/0x340 queue_delayed_work_on+0x48/0x70 afs_fl_release_private+0x57/0x70 locks_release_private+0x5c/0xa0 locks_free_lock+0xe/0x20 posix_lock_inode+0x55f/0x5b0 locks_lock_inode_wait+0x81/0x140 ? file_write_and_wait_range+0x50/0x70 afs_lock+0xcd/0x110 fcntl_setlk+0x10d/0x260 do_fcntl+0x24e/0x5b0 __do_sys_fcntl+0x6a/0x90 do_syscall_64+0x11e/0x310 entry_SYSCALL_64_after_hwframe+0x71/0x79 Fix this by reinitialising ->lock_work after allocating an inode. Also, flush ->lock_work when the inode is being evicted to make sure it's not still running.

Affected products

Linux
  • =<*
  • ==2.6.23
  • <2.6.23
  • <63d3f283858fae097fb09ddd4ce46bb0bc1f9d01
  • =<6.18.*
  • <5597fbd1e7c161914f20315a726e54025b0fdadb
  • =<7.1.*
  • <ebfd13c0367adb43d7c0a72f5cd7e004e60c6b28
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb: client: fix busy dentry warning on unmount after DIO

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix busy dentry warning on unmount after DIO Commit c68337442f03 ("cifs: Fix busy dentry used after unmounting") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb() to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: [dio] [cifsd] [close + umount] netfs_unbuffered_write_iter_locked ... cifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] ... netfs_write_subrequest_terminated netfs_subreq_clear_in_progress netfs_wake_collector // wake [1] netfs_put_subrequest netfs_put_request queue_work(system_dfl_wq, xxx) [2] // dio write return cifs_close _cifsFileInfo_put // cfile->count 2->1 --cfile->count [3] // umount cifs_kill_sb kill_anon_super // warning triggered! shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ... _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work(fileinfo_put_wq, xxx) [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput If the umount path is triggered before [5], it results warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] The existing per-inode ictx->io_count wait in cifs_evict_inode() does not help: it lives in the inode eviction path, which runs after shrink_dcache_for_umount() has already warned about the busy dentries. Fix it by adding a per-superblock outstanding-rreq counter that is incremented in cifs_init_request() and decremented in cifs_free_request(). In cifs_kill_sb(), before kill_anon_super(), wait for this counter to reach 0 - which guarantees that all cleanup_work for this sb have run and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Then drain the workqueue so the dentry refs are dropped. This is a targeted wait, not a flush of the system-wide system_dfl_wq.

Affected products

Linux
  • ==0629a1a187e424373364d681b42b101894bdb548
  • ==0e4b8faaaebe3137bec5723ef2b3cb0437fb38fd
  • ==708c276f516d27beaded7f372ac8111cee43926c
  • <f0eac9c3c3711f24efc2aaf12b8ec3e54a38c214
  • <6.2
  • <75f5c412fa867efa0bf9b646bffe0d912109e84a
  • <6.7
  • <6.13
  • <6.19
  • <6.20
  • =<*
  • ==7.0
  • <7.0
  • =<7.1.*
  • ==30afc6ea72cc6cf7c8d579e79b64232801c38d08
  • ==f655467a9973f964b267871e5fef533ad5014494
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Reject exclusive maps as inner maps in map-in-map

In the Linux kernel, the following vulnerability has been resolved: bpf: Reject exclusive maps as inner maps in map-in-map An exclusive map (created with excl_prog_hash) is bound to a single program by hash: check_map_prog_compatibility() refuses to load any program whose digest does not match map->excl_prog_sha. That check only runs for maps a program references directly, i.e. its used_maps. A map reached at runtime through a map-of-maps is never in used_maps, and bpf_map_meta_equal() does not consider excl_prog_sha, so an exclusive map can be inserted into a non-exclusive outer map and then looked up and mutated by an unrelated program, bypassing the exclusivity guarantee. For the signed loader this defeats the metadata map exclusivity check added in the signed loader: the cached map->sha[] is validated against the signed hash while another program on a hostile host rewrites the frozen map's contents through the outer map.

Affected products

Linux
  • <9a3c3c49c333760c8944dadacbe114c1884546ef
  • <3a0f73d27a8d379a8852a378b3c3208143e3b3b2
  • <6.18
  • =<*
  • ==6.18
  • =<6.18.*
  • =<7.1.*
  • <7c58ace08f180f8e249e714d1623388362f9d807
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path

In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.

Affected products

Linux
  • <a408d89e20d38d78f540e1951dc4c6056ad662e1
  • =<5.10.*
  • <edc7267b59a465c6ae7c5ffac2171c30962bd325
  • =<6.6.*
  • =<*
  • ==4.0
  • <e75717f9aec04355777be41070890c6a815c76df
  • =<6.18.*
  • <4ee41361c637eafa80f5d88b46d0016e6cdb24db
  • <8559b1501f77a5b5d003790bec170ca449e0c674
  • =<6.12.*
  • =<7.1.*
  • <3642d0a45214e3b4cf61bf5e75b04b490d0b3519
  • =<5.15.*
  • =<6.1.*
  • <4454caa204a2edb19c62754ddb96e5dbca0d2f49
  • <4.0
  • <c4d6442ac3ed00041fe4e1df715717ed78a7d37f