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
afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints

In the Linux kernel, the following vulnerability has been resolved: afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). Symlinks and mountpoints in AFS use afs_dir_aops, which does not provide a release_folio callback. However, afs_apply_status() unconditionally calls mapping_set_release_always() for these. In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() which returns true due to AS_RELEASE_ALWAYS being set. Since there is no release_folio callback, it falls through to try_to_free_buffers(), which at present expects buffer_heads to be not null. For symlinks and mountpoints without buffer_heads, this causes pointer dereference. [dh: Added more bits that were missed]

Affected products

Linux
  • <81e985b4c3a6cbcc443fcdcd3ebda7fcc845d459
  • ==6.14
  • =<*
  • <9d6b0f6d437e2f8350e08678e5e1d20c11c364f3
  • <6.14
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore

In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore esdhc_change_pinstate() checks for pins_100mhz and pins_200mhz at the top of the function and returns -EINVAL if either is not defined. This prevents the default case from ever being reached, which means devices with a sleep pinctrl state but without high-speed pin states (100mhz/ 200mhz) can never restore their default pin configuration. Move the IS_ERR checks for pins_100mhz and pins_200mhz into their respective switch cases.

Affected products

Linux
  • ==6.16
  • <bb72b2398c05fd0a4ebf13f49c7d599d7023d484
  • <6.16
  • <5adc14cd4b905629d5b9163b3a416dcab24c7ce2
  • <aa276aa6cbfbc5622bf974cf9be1d579ce4a5fab
  • =<*
  • =<6.18.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: ipip: require CAP_NET_ADMIN in the device netns for changelink

In the Linux kernel, the following vulnerability has been resolved: net: ipip: require CAP_NET_ADMIN in the device netns for changelink ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.

Affected products

Linux
  • <8211a26324667980a463c069469a818e71207e02
  • <3.12
  • <d49edcc65e0a37cc9b386a94415c5d6670ca8b71
  • =<6.6.*
  • =<*
  • <983cc4aa7e6f633b34c3ee743771252d7afa9a90
  • <68cadc3698c7de88966d306d12ec9c6217da228a
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • ==3.12
  • <26544021d5c49cc6ae8a968ccb5033e6363854a4
  • <91571643e554ae89a91942380d5f5361fb7060a2
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
perf/x86/amd/core: Avoid enabling BRS from the SVM reload path

In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Avoid enabling BRS from the SVM reload path Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users. When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP: Call Trace: <IRQ> amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410 __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 RIP: 0010:cpuidle_enter_state+0xc4/0x450 ? cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b </TASK> Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0.

Affected products

Linux
  • <e9b1a7411a667539c2f55e720bbb5f623b526a32
  • =<*
  • <7cc438c99bba324a0562b1bafa747b10f7e251df
  • <07c60dda9c059c09f83d42a3ebda2e7cc1cf3bc2
  • ==5.19
  • <46d0fd8535edce31f15e48d2de1bdee39a4850e5
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <5.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfs: Fix writethrough to use collection offload

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix writethrough to use collection offload Fix writethrough write to set NETFS_RREQ_OFFLOAD_COLLECTION on the request so that collection is processed asynchronously rather than only right at the end - and also so that asynchronous O_SYNC writes get collected at all.

Affected products

Linux
  • <6.10
  • ==6.10
  • =<*
  • <ba6a9f6533c77c628eef0c0c5c19cd316e2be1b4
  • =<6.18.*
  • =<7.1.*
  • <0348e3fa0dfbf152af687e86ce079742b1860da9
  • <7838131e296dfbb639ea278901a53c018322c11e
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.

Affected products

Linux
  • <4.2
  • <8087bb360a936a6314d22b567e4b861656943eb6
  • <c9787d7c24ffd83019f379455e1b97fb4f0f75eb
  • =<5.10.*
  • <93a775fd67f3ef34949a9523bfa69403ee74efdd
  • =<6.6.*
  • =<*
  • <3ca9982a8882470aa0ac4e8bb9a552b181d1efcd
  • ==4.2
  • <6e98407cb94e035bba98956adc9096a76d8b2a9f
  • <50b70f56f3baaff46599f59b2d93fa2540120776
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • =<5.15.*
  • <fcb565966534909377a16be5f7b065db2e25c8b5
  • =<6.1.*
  • <d01b4b471f0fc5c396af62845e972ccf99cee29a
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fbdev: sm501fb: Fix buffer errors in OF binding code

In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, "mode", &len) is just written over either the static "640x480-16@60" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.

Affected products

Linux
  • <48cf0f4c6581ec90104cec9c5bf794a8bf347e30
  • =<5.10.*
  • <9057e3f5db39f0ef0dac2f59f2bc59bf17e36c31
  • <2.6.39
  • <de590cdf7efec8a0b6da90ae2ab5fc5df26810b9
  • <d8421e09382cfe0bd2a044c8b0a822f64855dd4e
  • =<6.6.*
  • =<*
  • <b2ff450f7f5cfc7143cab57c3ad70293ba8b822a
  • =<6.18.*
  • =<6.12.*
  • <d374f76e1257ecc5d691a765c512ed2c29a44741
  • =<7.1.*
  • =<5.15.*
  • <47008d59c60ed896085da95f8d4dd40e1677dd3a
  • <0bc3d909a49e1fd8b8c3f2160d526e672c40621d
  • =<6.1.*
  • ==2.6.39
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
handshake: Require admin permission for DONE command

In the Linux kernel, the following vulnerability has been resolved: handshake: Require admin permission for DONE command ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENL_ADMIN_PERM; DONE has no privilege check at all. The fd-lookup in handshake_nl_done_doit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKE_A_DONE_STATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result.

Affected products

Linux
  • <b6557f912509abe8e70223373dd7a44d1d4a0d6c
  • <4dafc411948469277b276724c3b2b4408c02c04c
  • <81246a65303d9635266b1334490142caaf86a11f
  • =<6.6.*
  • =<*
  • <6.4
  • <25fb53e43ec006ac69b9e825a7e8a11d63a6083e
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <67cec2f1eb9e58719d622e92e2278ceda72dbd85
  • ==6.4
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
vxlan: use neigh_ha_snapshot() in route_shortcircuit()

In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.

Affected products

Linux
  • =<6.6.*
  • <d08e8ac13f2e228cc7fc3c70b5ebe71557b624a0
  • ==3.8
  • =<*
  • <05f2987f73daa05333fd713d05546142f9f7c5f0
  • <8eca411347e1d38964f9ed2c8d3b6ab0e7e4473d
  • <ff89415d34c3ab9f5312316423122e664ed3524f
  • <ec341bb76d77b4c2948764375ee6bfeef4bb41c3
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <3.8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()

In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer() When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt). However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report() If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1. In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked. Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released.

Affected products

Linux
  • <3546deaa0c30a14c7cdb5dc8f2432cb428f0cd36
  • <f60ec3058a85447008b88b762c859d336163acb3
  • =<*
  • =<6.18.*
  • <95128dc74425ec19ed4f2077ccc651e791ff4b75
  • <2.6.12
  • =<7.1.*
  • ==2.6.12