Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()<br /> <br /> When iptfs_skb_add_frags() copies frag references from the source<br /> frag walk into a new SKB, it increments the page reference count via<br /> __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the<br /> destination SKB&amp;#39;s skb_shinfo-&gt;flags.<br /> <br /> If the source SKB carries shared frags (e.g. from a page-pool backed<br /> receive path), the new inner SKB will appear to ESP as having privately<br /> owned frags. A subsequent esp_input() call for a nested transport-mode<br /> SA then takes the no-COW fast path and decrypts in place, writing over<br /> pages that are still referenced by the outer IPTFS SKB. This causes<br /> kernel-visible memory corruption and can trigger a panic.<br /> <br /> All other frag-transfer helpers in the kernel (skb_try_coalesce,<br /> skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly<br /> propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this<br /> convention by setting the flag inside the loop immediately after<br /> __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag<br /> unconditionally propagates SKBFL_SHARED_FRAG.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure<br /> <br /> ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old<br /> template before allocating the replacement. If the kzalloc() then fails,<br /> it returns -ENOMEM while link-&gt;u.ap.unsol_bcast_probe_resp still points<br /> at the object already queued for freeing. A later update or AP teardown<br /> re-queues that same rcu_head; the second free is caught by KASAN when the<br /> RCU sheaf is processed in softirq:<br /> <br /> BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850)<br /> Free of addr ffff88800d06f300 by task exploit/145<br /> ...<br /> __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940)<br /> rcu_free_sheaf (mm/slub.c:5850)<br /> rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869)<br /> handle_softirqs (kernel/softirq.c:622)<br /> The buggy address belongs to the cache kmalloc-128 of size 128<br /> <br /> Queue the old object for kfree_rcu() only after the new one is published,<br /> matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix fils_discovery double free on alloc failure<br /> <br /> ieee80211_set_fils_discovery() calls kfree_rcu() on the old template<br /> before allocating the replacement. If the kzalloc() then fails, it<br /> returns -ENOMEM while link-&gt;u.ap.fils_discovery still points at the<br /> object already queued for freeing. A later update or AP teardown<br /> (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is<br /> caught by KASAN when the RCU sheaf is processed in softirq:<br /> <br /> BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850)<br /> Free of addr ffff88800c065280 by task swapper/0/0<br /> ...<br /> __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940)<br /> rcu_free_sheaf (mm/slub.c:5850)<br /> rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869)<br /> handle_softirqs (kernel/softirq.c:622)<br /> The buggy address belongs to the cache kmalloc-96 of size 96<br /> <br /> Queue the old object for kfree_rcu() only after the new one is published,<br /> matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject free space cache with more entries than pages<br /> <br /> When loading a v1 free space cache, __load_free_space_cache() takes<br /> num_entries and num_bitmaps straight from the on-disk<br /> btrfs_free_space_header. That header is stored in the tree_root under a key<br /> with type 0, which the tree-checker has no case for, so neither count is<br /> validated before the load trusts it.<br /> <br /> The load loops num_entries times and maps the next page whenever the current<br /> one runs out, going through io_ctl_check_crc() -&gt; io_ctl_map_page(), which<br /> does io_ctl-&gt;pages[io_ctl-&gt;index++]. But pages[] is allocated in<br /> io_ctl_init() from the cache inode&amp;#39;s i_size, not from num_entries:<br /> <br /> num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);<br /> io_ctl-&gt;pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);<br /> <br /> So if num_entries claims more records than the pages can hold, io_ctl-&gt;index<br /> runs off the end of pages[]. The write side never hits this because<br /> io_ctl_add_entry() and io_ctl_add_bitmap() both stop once<br /> io_ctl-&gt;index &gt;= io_ctl-&gt;num_pages; the read side just never had the same<br /> check.<br /> <br /> To trigger it, take a clean cache (num_entries = here), set num_entries<br /> in the header to 0x10000, and fix up the leaf checksum so it still passes<br /> the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and<br /> pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read<br /> 65536 entries, io_ctl-&gt;index walks up to 16, and pages[16] is read past the<br /> array:<br /> <br /> BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)<br /> Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58<br /> io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)<br /> __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820)<br /> load_free_space_cache (fs/btrfs/free-space-cache.c:1017)<br /> caching_thread (fs/btrfs/block-group.c:880)<br /> btrfs_work_helper (fs/btrfs/async-thread.c:312)<br /> process_one_work<br /> worker_thread<br /> kthread<br /> ret_from_fork<br /> <br /> free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc()<br /> at line 565, which is why that is the frame KASAN names. The out-of-bounds<br /> slot is then treated as a struct page and handed to crc32c(), so the bad<br /> read turns into a GP fault.<br /> <br /> Add the missing check to io_ctl_check_crc(), which is where both the entry<br /> loop and the bitmap loop end up. When num_entries is too large the load now<br /> fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds<br /> the free space from the extent tree, so a valid cache is never rejected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n<br /> <br /> On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed<br /> attribute table itself instead of calling ip_valid_fib_dump_req(). The<br /> RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is<br /> present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no<br /> RTA_OIF hits a NULL dereference.<br /> <br /> RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without<br /> CAP_NET_ADMIN, so an unprivileged user can trigger it.<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189)<br /> Call Trace:<br /> mpls_dump_routes (net/mpls/af_mpls.c:2236)<br /> netlink_dump (net/netlink/af_netlink.c:2331)<br /> __netlink_dump_start (net/netlink/af_netlink.c:2446)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:7033)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2556)<br /> netlink_unicast (net/netlink/af_netlink.c:1345)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1900)<br /> __sock_sendmsg (net/socket.c:790)<br /> ____sys_sendmsg (net/socket.c:2684)<br /> ___sys_sendmsg (net/socket.c:2738)<br /> __sys_sendmsg (net/socket.c:2770)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> Skip unset attributes, as ip_valid_fib_dump_req() does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: p54: validate RX frame length in p54_rx_eeprom_readback()<br /> <br /> p54_rx_eeprom_readback() copies the requested EEPROM slice out of a<br /> device-supplied readback frame without checking that the skb actually holds<br /> that many bytes. Commit da1b9a55ff11 ("wifi: p54: prevent buffer-overflow in<br /> p54_rx_eeprom_readback()") closed the destination overflow by copying a<br /> fixed priv-&gt;eeprom_slice_size (and rejecting a mismatched advertised len),<br /> but the source side is still unbounded: nothing verifies the frame is long<br /> enough to supply that many bytes.<br /> <br /> A malicious USB device can send a short frame whose advertised len matches<br /> priv-&gt;eeprom_slice_size while the payload is truncated. The equality check<br /> passes and memcpy() reads past the end of the skb, leaking adjacent heap:<br /> <br /> BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507)<br /> Read of size 1016 at addr ffff88800f077114 by task swapper/0/0<br /> Call Trace:<br /> <br /> ...<br /> __asan_memcpy (mm/kasan/shadow.c:105)<br /> p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507)<br /> p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163)<br /> __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)<br /> dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005)<br /> ...<br /> <br /> <br /> The buggy address belongs to the object at ffff88800f0770c0<br /> which belongs to the cache skbuff_small_head of size 704<br /> The buggy address is located 84 bytes inside of<br /> allocated 704-byte region [ffff88800f0770c0, ffff88800f077380)<br /> <br /> Check that the slice fits in the skb before copying.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: fib: free fib_alias with kfree_rcu() on insert error path<br /> <br /> fib_table_insert() publishes new_fa into the leaf&amp;#39;s fa_list with<br /> fib_insert_alias() before calling the fib entry notifiers. When a<br /> notifier fails, the error path removes new_fa with fib_remove_alias()<br /> (hlist_del_rcu) and frees it right away with kmem_cache_free().<br /> <br /> fib_table_lookup() walks that list under rcu_read_lock() only, so a<br /> concurrent lookup that already reached new_fa keeps reading it after the<br /> free:<br /> <br /> BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601)<br /> Read of size 1 at addr ffff88810676d4eb by task exploit/297<br /> Call Trace:<br /> fib_table_lookup (net/ipv4/fib_trie.c:1601)<br /> ip_route_output_key_hash_rcu (net/ipv4/route.c:2814)<br /> ip_route_output_key_hash (net/ipv4/route.c:2705)<br /> __ip4_datagram_connect (net/ipv4/datagram.c:49)<br /> udp_connect (net/ipv4/udp.c:2144)<br /> __sys_connect (net/socket.c:2167)<br /> __x64_sys_connect (net/socket.c:2173)<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> which belongs to the cache ip_fib_alias of size 56<br /> <br /> Triggering the error path needs CAP_NET_ADMIN and a registered fib<br /> notifier that can reject a route; a netdevsim device whose IPv4 FIB<br /> resource is exhausted is enough.<br /> <br /> Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already<br /> does for a fib_alias removed from the trie.

** UNSUPPORTED WHEN ASSIGNED ** Stack-based Buffer Overflow vulnerability in Apache Lucy.<br /> <br /> This issue affects Apache Lucy: all versions.<br /> <br /> As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.<br /> <br /> NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Memory Allocation with Excessive Size Value vulnerability in Apache Lucy.<br /> <br /> This issue affects Apache Lucy: all versions.<br /> <br /> As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.<br /> <br /> NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Lucy.<br /> <br /> This issue affects Apache Lucy: all versions.<br /> <br /> As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.<br /> <br /> NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Uncontrolled Recursion vulnerability in Apache Lucy.<br /> <br /> This issue affects Apache Lucy: all versions.<br /> <br /> As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.<br /> <br /> NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

The Multi Uploader for Gravity Forms plugin for WordPress is vulnerable to unauthorized arbitrary media deletion in all versions up to, and including, 1.1.8. This is due to missing capability checks in the `plupload_ajax_delete_file()` function, which is registered via `wp_ajax_nopriv_gfmu_delete_file`. The nonce intended for CSRF protection is exposed on any public-facing page containing a multi-uploader form field via the `GFMU_options` JavaScript object. This makes it possible for unauthenticated attackers to permanently delete any WordPress media attachment by supplying its attachment ID, potentially leading to complete media library destruction.