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, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
s390/ap: use generic driver_override infrastructure

In the Linux kernel, the following vulnerability has been resolved: s390/ap: use generic driver_override infrastructure When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released. This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF. Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock. Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead. Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store().

Affected products

Linux
  • =<7.0.*
  • <6.19
  • <8f2eca0570438b94602da1297353eb7b10dcb6cb
  • =<*
  • <81d6f7c3a70b10ff757ee8b5f8114a190871cf1e
  • ==6.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net_sched: fix skb memory leak in deferred qdisc drops

In the Linux kernel, the following vulnerability has been resolved: net_sched: fix skb memory leak in deferred qdisc drops When the network stack cleans up the deferred list via qdisc_run_end(), it operates on the root qdisc. If the root qdisc do not implement the TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and gets stranded on the child's local to_free list. Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If the flag is present, the packet is appended directly to the root's to_free list. Otherwise, drop it directly as it was done before the optimization was implemented.

Affected products

Linux
  • <6.19
  • =<7.0.*
  • <bf26ad92ffda7884825d67b46bd5efe615c3babf
  • =<*
  • ==6.19
  • <a6bd339dbb3514bce690fdcf252e788dfab4ee76
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/rds: Restrict use of RDS/IB to the initial network namespace

In the Linux kernel, the following vulnerability has been resolved: net/rds: Restrict use of RDS/IB to the initial network namespace Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces.

Affected products

Linux
  • =<6.1.*
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • <b6a54f5e9ce9b97ae641855378d71c5154a085c0
  • <07035306bf722f4676a1aee35cbeb3732c76194e
  • <ebf71dd4aff46e8e421d455db3e231ba43d2fa8a
  • =<7.0.*
  • <fb407343c0c16e94584707b2dfdd350a5f81b000
  • <3e7f14cd5a51533404e1ae4809caab46073fb5c7
  • <c244b79adffad89a5173cf8bfaa06a6b40bbd09b
  • ==4.3
  • =<*
  • <3174fc703d081d2ca538b22fba734e3ad5b52322
  • <4.3
  • =<5.10.*
  • <a7494479757d60d2413bfaa087f8431a26eea032
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nf_conntrack_sip: don't use simple_strtoul

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: don't use simple_strtoul Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(), and ct_sip_parse_request() with a new sip_parse_port() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings. The previous code dereferenced pointers without bounds checks after sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed. Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes: - Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters. - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10. - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range. - epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it. Based on an earlier patch from Jenny Guanni Qu <qguanni@gmail.com>.

Affected products

Linux
  • =<6.1.*
  • ==2.6.26
  • =<5.15.*
  • =<6.18.*
  • <9c6afcb1c3cbb2c0da65b8515ac14d7273872f84
  • =<7.0.*
  • <b3264c977e79d8a25778d4fd11520f00fea1329c
  • <8cd0358379570003659186706e077929d6930c40
  • <2.6.26
  • <7df9863bf538a626e8a684e59cb2c43eac0ef3c8
  • =<*
  • <9f69c323ae0ab517e595c2cc74e0ae0d9d085611
  • <8cf6809cddcbe301aedfc6b51bcd4944d45795f6
  • <523762e3b6933fff81f01dfa3c60c0774044cdab
  • =<6.12.*
  • =<5.10.*
  • <ea2ecd29b8f4433e52607192ca91084f95787ca0
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
libceph: Fix potential out-of-bounds access in crush_decode()

In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in crush_decode() A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().

Affected products

Linux
  • =<6.18.*
  • <5.15.209
  • <6e70ef53e818c53eab28d7b0026b7fd03dddaba5
  • =<7.0.*
  • <ea0d42137f0c06da71e37ffc647aab4c5309599a
  • <5.10.258
  • =<6.1.*
  • <6.18.33
  • <4c79fc2d598694bda845b46229c9d48b65042970
  • <7.0.10
  • <fb176a99e4c1a5a8448a83d83d3606203ba81faa
  • <ebe76d58a48a48031b98543d86c4cd30a825b622
  • <6.1.175
  • <6.6.141
  • <0f3604cbe4df14c5e58288ac9f57511e726a222d
  • =<5.15.*
  • =<*
  • <6.12.91
  • <cceb10023e76bc89f3fe9238ebd0ccab0fc7c7c5
  • =<6.12.*
  • =<5.10.*
  • <3f42508191e129ee6b5ea96578d5cab14f2a013a
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tipc: fix double-free in tipc_buf_append()

In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.

Affected products

Linux
  • <0274f24485fc38032d4093e463dc3ff5c7a667c9
  • =<5.15.*
  • =<6.18.*
  • <4d104882bc815d4ec666ace9155f5f52715879a6
  • <29940fff14110ca48c5ccc168d121665b51bb778
  • =<6.12.*
  • =<7.0.*
  • <4ee4deadaae7cb2e3d53af0fc889cf92a73413c0
  • <4.15
  • <d3556656c6daebf8def751c7e71d11dd0a180d24
  • =<*
  • <a438975a6dcdbd70865978c021650d1485586f0b
  • <1d5e589055880fae229e229e1929e087dbe08cf3
  • <d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a
  • =<6.1.*
  • =<5.10.*
  • ==4.15
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg

In the Linux kernel, the following vulnerability has been resolved: NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg In nfsd4_add_rdaccess_to_wrdeleg, if fp->fi_fds[O_RDONLY] is already set by another thread, __nfs4_file_get_access should not be called to increment the nfs4_file access count since that was already done by the thread that added READ access to the file. The extra fi_access count in nfs4_file can prevent the corresponding nfsd_file from being freed. When stopping nfs-server service, these extra access counts trigger a BUG in kmem_cache_destroy() that shows nfsd_file object remaining on __kmem_cache_shutdown. This problem can be reproduced by running the Git project's test suite over NFS.

Affected products

Linux
  • =<6.18.*
  • <6.19
  • =<7.0.*
  • =<*
  • <b81572b073441dfd32213e41857676d0dbff4665
  • <4584229395d0d65bd517780afe97ffea07cb2c3d
  • <b48f44f36e6607b2f818560f19deb86b4a9c717b
  • ==6.19
  • <6.18.33
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nexthop: fix IPv6 route referencing IPv4 nexthop

In the Linux kernel, the following vulnerability has been resolved: nexthop: fix IPv6 route referencing IPv4 nexthop syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3

Affected products

Linux
  • <9c2d6770a5f4545a307eb66979bef7656a34d621
  • =<6.1.*
  • =<5.15.*
  • =<6.18.*
  • <aaac3bed034239e1d75732211d9b05f30b0b4f35
  • <b3b7e850e1541f0520c4a12ec884255c30427ff6
  • <613c8f4a501421dd258b07ea614205d4e16ec845
  • =<6.12.*
  • <ceffe81a0be92afc0cd1340bc8ca46559cce9bb4
  • <29c95185ba32b621fbc3800fb86e7dc3edf5c2be
  • =<7.0.*
  • <5.3
  • <6275796f22bb382f3e9aa58ed0b4ef7bdad78cb8
  • <ad85961004fd4bd2f31209ac4b07612c6cefb9e7
  • =<*
  • ==5.3
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xfrm: ipcomp: Free destination pages on acomp errors

In the Linux kernel, the following vulnerability has been resolved: xfrm: ipcomp: Free destination pages on acomp errors Move the out_free_req label up by a couple of lines so that the allocated dst SG list gets freed on error as well as success.

Affected products

Linux
  • <6.15
  • =<6.18.*
  • <dc6dcba80d72a27ab61831ad3d253316e0c9b9d5
  • =<7.0.*
  • <b30aa173c3809f6af4c83a86099be1be19aa48eb
  • ==6.15
  • =<*
  • <7dbac7680eb629b3b4dc7e98c34f943b8814c0c8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix use-after-free in offloaded map/prog info fill

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.

Affected products

Linux
  • <a0c584fc18056709c8e047a82a6045d6c209f4ce
  • ==4.16
  • <4.16
  • =<7.0.*
  • =<*
  • <a51e7fbe94a87e236631a83973d4f558310b2cd2