Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: fix UAF in direct writes<br /> <br /> In production we have been hitting the following warning consistently<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0<br /> Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]<br /> RIP: 0010:refcount_warn_saturate+0x9c/0xe0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0x9f/0x130<br /> ? refcount_warn_saturate+0x9c/0xe0<br /> ? report_bug+0xcc/0x150<br /> ? handle_bug+0x3d/0x70<br /> ? exc_invalid_op+0x16/0x40<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? refcount_warn_saturate+0x9c/0xe0<br /> nfs_direct_write_schedule_work+0x237/0x250 [nfs]<br /> process_one_work+0x12f/0x4a0<br /> worker_thread+0x14e/0x3b0<br /> ? ZSTD_getCParams_internal+0x220/0x220<br /> kthread+0xdc/0x120<br /> ? __btf_name_valid+0xa0/0xa0<br /> ret_from_fork+0x1f/0x30<br /> <br /> This is because we&amp;#39;re completing the nfs_direct_request twice in a row.<br /> <br /> The source of this is when we have our commit requests to submit, we<br /> process them and send them off, and then in the completion path for the<br /> commit requests we have<br /> <br /> if (nfs_commit_end(cinfo.mds))<br /> nfs_direct_write_complete(dreq);<br /> <br /> However since we&amp;#39;re submitting asynchronous requests we sometimes have<br /> one that completes before we submit the next one, so we end up calling<br /> complete on the nfs_direct_request twice.<br /> <br /> The only other place we use nfs_generic_commit_list() is in<br /> __nfs_commit_inode, which wraps this call in a<br /> <br /> nfs_commit_begin();<br /> nfs_commit_end();<br /> <br /> Which is a common pattern for this style of completion handling, one<br /> that is also repeated in the direct code with get_dreq()/put_dreq()<br /> calls around where we process events as well as in the completion paths.<br /> <br /> Fix this by using the same pattern for the commit requests.<br /> <br /> Before with my 200 node rocksdb stress running this warning would pop<br /> every 10ish minutes. With my patch the stress test has been running for<br /> several hours without popping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: swap: fix race between free_swap_and_cache() and swapoff()<br /> <br /> There was previously a theoretical window where swapoff() could run and<br /> teardown a swap_info_struct while a call to free_swap_and_cache() was<br /> running in another thread. This could cause, amongst other bad<br /> possibilities, swap_page_trans_huge_swapped() (called by<br /> free_swap_and_cache()) to access the freed memory for swap_map.<br /> <br /> This is a theoretical problem and I haven&amp;#39;t been able to provoke it from a<br /> test case. But there has been agreement based on code review that this is<br /> possible (see link below).<br /> <br /> Fix it by using get_swap_device()/put_swap_device(), which will stall<br /> swapoff(). There was an extra check in _swap_info_get() to confirm that<br /> the swap entry was not free. This isn&amp;#39;t present in get_swap_device()<br /> because it doesn&amp;#39;t make sense in general due to the race between getting<br /> the reference and swapoff. So I&amp;#39;ve added an equivalent check directly in<br /> free_swap_and_cache().<br /> <br /> Details of how to provoke one possible issue (thanks to David Hildenbrand<br /> for deriving this):<br /> <br /> --8try_to_unuse() will stop as soon as soon as si-&gt;inuse_pages==0.<br /> <br /> So the question is: could someone reclaim the folio and turn<br /> si-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().<br /> <br /> Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are<br /> still references by swap entries.<br /> <br /> Process 1 still references subpage 0 via swap entry.<br /> Process 2 still references subpage 1 via swap entry.<br /> <br /> Process 1 quits. Calls free_swap_and_cache().<br /> -&gt; count == SWAP_HAS_CACHE<br /> [then, preempted in the hypervisor etc.]<br /> <br /> Process 2 quits. Calls free_swap_and_cache().<br /> -&gt; count == SWAP_HAS_CACHE<br /> <br /> Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls<br /> __try_to_reclaim_swap().<br /> <br /> __try_to_reclaim_swap()-&gt;folio_free_swap()-&gt;delete_from_swap_cache()-&gt;<br /> put_swap_folio()-&gt;free_swap_slot()-&gt;swapcache_free_entries()-&gt;<br /> swap_entry_free()-&gt;swap_range_free()-&gt;<br /> ...<br /> WRITE_ONCE(si-&gt;inuse_pages, si-&gt;inuse_pages - nr_entries);<br /> <br /> What stops swapoff to succeed after process 2 reclaimed the swap cache<br /> but before process1 finished its call to swap_page_trans_huge_swapped()?<br /> <br /> --8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: fix llsec key resources release in mac802154_llsec_key_del<br /> <br /> mac802154_llsec_key_del() can free resources of a key directly without<br /> following the RCU rules for waiting before the end of a grace period. This<br /> may lead to use-after-free in case llsec_lookup_key() is traversing the<br /> list of keys in parallel with a key deletion:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0<br /> Modules linked in:<br /> CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x162/0x2a0<br /> Call Trace:<br /> <br /> llsec_lookup_key.isra.0+0x890/0x9e0<br /> mac802154_llsec_encrypt+0x30c/0x9c0<br /> ieee802154_subif_start_xmit+0x24/0x1e0<br /> dev_hard_start_xmit+0x13e/0x690<br /> sch_direct_xmit+0x2ae/0xbc0<br /> __dev_queue_xmit+0x11dd/0x3c20<br /> dgram_sendmsg+0x90b/0xd60<br /> __sys_sendto+0x466/0x4c0<br /> __x64_sys_sendto+0xe0/0x1c0<br /> do_syscall_64+0x45/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Also, ieee802154_llsec_key_entry structures are not freed by<br /> mac802154_llsec_key_del():<br /> <br /> unreferenced object 0xffff8880613b6980 (size 64):<br /> comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)<br /> hex dump (first 32 bytes):<br /> 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......".......<br /> 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e2/0x2d0<br /> [] kmalloc_trace+0x25/0xc0<br /> [] mac802154_llsec_key_add+0xac9/0xcf0<br /> [] ieee802154_add_llsec_key+0x5a/0x80<br /> [] nl802154_add_llsec_key+0x426/0x5b0<br /> [] genl_family_rcv_msg_doit+0x1fe/0x2f0<br /> [] genl_rcv_msg+0x531/0x7d0<br /> [] netlink_rcv_skb+0x169/0x440<br /> [] genl_rcv+0x28/0x40<br /> [] netlink_unicast+0x53c/0x820<br /> [] netlink_sendmsg+0x93b/0xe60<br /> [] ____sys_sendmsg+0xac5/0xca0<br /> [] ___sys_sendmsg+0x11d/0x1c0<br /> [] __sys_sendmsg+0xfa/0x1d0<br /> [] do_syscall_64+0x45/0xf0<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Handle the proper resource release in the RCU callback function<br /> mac802154_llsec_key_del_rcu().<br /> <br /> Note that if llsec_lookup_key() finds a key, it gets a refcount via<br /> llsec_key_get() and locally copies key id from key_entry (which is a<br /> list element). So it&amp;#39;s safe to call llsec_key_put() and free the list<br /> entry after the RCU grace period elapses.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: esp: fix bad handling of pages from page_pool<br /> <br /> When the skb is reorganized during esp_output (!esp-&gt;inline), the pages<br /> coming from the original skb fragments are supposed to be released back<br /> to the system through put_page. But if the skb fragment pages are<br /> originating from a page_pool, calling put_page on them will trigger a<br /> page_pool leak which will eventually result in a crash.<br /> <br /> This leak can be easily observed when using CONFIG_DEBUG_VM and doing<br /> ipsec + gre (non offloaded) forwarding:<br /> <br /> BUG: Bad page state in process ksoftirqd/16 pfn:1451b6<br /> page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6<br /> flags: 0x200000000000000(node=0|zone=2)<br /> page_type: 0xffffffff()<br /> raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000<br /> raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000<br /> page dumped because: page_pool leak<br /> Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core]<br /> CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x36/0x50<br /> bad_page+0x70/0xf0<br /> free_unref_page_prepare+0x27a/0x460<br /> free_unref_page+0x38/0x120<br /> esp_ssg_unref.isra.0+0x15f/0x200<br /> esp_output_tail+0x66d/0x780<br /> esp_xmit+0x2c5/0x360<br /> validate_xmit_xfrm+0x313/0x370<br /> ? validate_xmit_skb+0x1d/0x330<br /> validate_xmit_skb_list+0x4c/0x70<br /> sch_direct_xmit+0x23e/0x350<br /> __dev_queue_xmit+0x337/0xba0<br /> ? nf_hook_slow+0x3f/0xd0<br /> ip_finish_output2+0x25e/0x580<br /> iptunnel_xmit+0x19b/0x240<br /> ip_tunnel_xmit+0x5fb/0xb60<br /> ipgre_xmit+0x14d/0x280 [ip_gre]<br /> dev_hard_start_xmit+0xc3/0x1c0<br /> __dev_queue_xmit+0x208/0xba0<br /> ? nf_hook_slow+0x3f/0xd0<br /> ip_finish_output2+0x1ca/0x580<br /> ip_sublist_rcv_finish+0x32/0x40<br /> ip_sublist_rcv+0x1b2/0x1f0<br /> ? ip_rcv_finish_core.constprop.0+0x460/0x460<br /> ip_list_rcv+0x103/0x130<br /> __netif_receive_skb_list_core+0x181/0x1e0<br /> netif_receive_skb_list_internal+0x1b3/0x2c0<br /> napi_gro_receive+0xc8/0x200<br /> gro_cell_poll+0x52/0x90<br /> __napi_poll+0x25/0x1a0<br /> net_rx_action+0x28e/0x300<br /> __do_softirq+0xc3/0x276<br /> ? sort_range+0x20/0x20<br /> run_ksoftirqd+0x1e/0x30<br /> smpboot_thread_fn+0xa6/0x130<br /> kthread+0xcd/0x100<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x31/0x50<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> The suggested fix is to introduce a new wrapper (skb_page_unref) that<br /> covers page refcounting for page_pool pages as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: fix reference counting on zcrypt card objects<br /> <br /> Tests with hot-plugging crytpo cards on KVM guests with debug<br /> kernel build revealed an use after free for the load field of<br /> the struct zcrypt_card. The reason was an incorrect reference<br /> handling of the zcrypt card object which could lead to a free<br /> of the zcrypt card object while it was still in use.<br /> <br /> This is an example of the slab message:<br /> <br /> kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b<br /> kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43<br /> kernel: kmalloc_trace+0x3f2/0x470<br /> kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]<br /> kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]<br /> kernel: ap_device_probe+0x15c/0x290<br /> kernel: really_probe+0xd2/0x468<br /> kernel: driver_probe_device+0x40/0xf0<br /> kernel: __device_attach_driver+0xc0/0x140<br /> kernel: bus_for_each_drv+0x8c/0xd0<br /> kernel: __device_attach+0x114/0x198<br /> kernel: bus_probe_device+0xb4/0xc8<br /> kernel: device_add+0x4d2/0x6e0<br /> kernel: ap_scan_adapter+0x3d0/0x7c0<br /> kernel: ap_scan_bus+0x5a/0x3b0<br /> kernel: ap_scan_bus_wq_callback+0x40/0x60<br /> kernel: process_one_work+0x26e/0x620<br /> kernel: worker_thread+0x21c/0x440<br /> kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43<br /> kernel: kfree+0x37e/0x418<br /> kernel: zcrypt_card_put+0x54/0x80 [zcrypt]<br /> kernel: ap_device_remove+0x4c/0xe0<br /> kernel: device_release_driver_internal+0x1c4/0x270<br /> kernel: bus_remove_device+0x100/0x188<br /> kernel: device_del+0x164/0x3c0<br /> kernel: device_unregister+0x30/0x90<br /> kernel: ap_scan_adapter+0xc8/0x7c0<br /> kernel: ap_scan_bus+0x5a/0x3b0<br /> kernel: ap_scan_bus_wq_callback+0x40/0x60<br /> kernel: process_one_work+0x26e/0x620<br /> kernel: worker_thread+0x21c/0x440<br /> kernel: kthread+0x150/0x168<br /> kernel: __ret_from_fork+0x3c/0x58<br /> kernel: ret_from_fork+0xa/0x30<br /> kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)<br /> kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88<br /> kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........<br /> kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.<br /> kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........<br /> kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ<br /> kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2<br /> kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)<br /> kernel: Call Trace:<br /> kernel: [] dump_stack_lvl+0x90/0x120<br /> kernel: [] check_bytes_and_report+0x114/0x140<br /> kernel: [] check_object+0x334/0x3f8<br /> kernel: [] alloc_debug_processing+0xc4/0x1f8<br /> kernel: [] get_partial_node.part.0+0x1ee/0x3e0<br /> kernel: [] ___slab_alloc+0xaf4/0x13c8<br /> kernel: [] __slab_alloc.constprop.0+0x78/0xb8<br /> kernel: [] __kmalloc+0x434/0x590<br /> kernel: [] ext4_htree_store_dirent+0x4e/0x1c0<br /> kernel: [] htree_dirblock_to_tree+0x17a/0x3f0<br /> kernel: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix failure to detect DAT corruption in btree and direct mappings<br /> <br /> Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".<br /> <br /> This resolves a kernel BUG reported by syzbot. Since there are two<br /> flaws involved, I&amp;#39;ve made each one a separate patch.<br /> <br /> The first patch alone resolves the syzbot-reported bug, but I think<br /> both fixes should be sent to stable, so I&amp;#39;ve tagged them as such.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data<br /> to a nilfs2 file system whose metadata is corrupted.<br /> <br /> There are two flaws involved in this issue.<br /> <br /> The first flaw is that when nilfs_get_block() locates a data block using<br /> btree or direct mapping, if the disk address translation routine<br /> nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata<br /> corruption, it can be passed back to nilfs_get_block(). This causes<br /> nilfs_get_block() to misidentify an existing block as non-existent,<br /> causing both data block lookup and insertion to fail inconsistently.<br /> <br /> The second flaw is that nilfs_get_block() returns a successful status in<br /> this inconsistent state. This causes the caller __block_write_begin_int()<br /> or others to request a read even though the buffer is not mapped,<br /> resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()<br /> failing.<br /> <br /> This fixes the first issue by changing the return value to code -EINVAL<br /> when a conversion using DAT fails with code -ENOENT, avoiding the<br /> conflicting condition that leads to the kernel bug described above. Here,<br /> code -EINVAL indicates that metadata corruption was detected during the<br /> block lookup, which will be properly handled as a file system error and<br /> converted to -EIO when passing through the nilfs2 bmap layer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: prevent kernel bug at submit_bh_wbc()<br /> <br /> Fix a bug where nilfs_get_block() returns a successful status when<br /> searching and inserting the specified block both fail inconsistently. If<br /> this inconsistent behavior is not due to a previously fixed bug, then an<br /> unexpected race is occurring, so return a temporary error -EAGAIN instead.<br /> <br /> This prevents callers such as __block_write_begin_int() from requesting a<br /> read into a buffer that is not mapped, which would cause the BUG_ON check<br /> for the BH_Mapped flag in submit_bh_wbc() to fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix potencial out-of-bounds when buffer offset is invalid<br /> <br /> I found potencial out-of-bounds when buffer offset fields of a few requests<br /> is invalid. This patch set the minimum value of buffer offset field to<br /> -&gt;Buffer offset to validate buffer length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()<br /> <br /> If -&gt;NameOffset of smb2_create_req is smaller than Buffer offset of<br /> smb2_create_req, slab-out-of-bounds read can happen from smb2_open.<br /> This patch set the minimum value of the name offset to the buffer offset<br /> to validate name length of smb2_create_req().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: netlink: access device through ctx instead of peer<br /> <br /> The previous commit fixed a bug that led to a NULL peer-&gt;device being<br /> dereferenced. It&amp;#39;s actually easier and faster performance-wise to<br /> instead get the device from ctx-&gt;wg. This semantically makes more sense<br /> too, since ctx-&gt;wg-&gt;peer_allowedips.seq is compared with<br /> ctx-&gt;allowedips_seq, basing them both in ctx. This also acts as a<br /> defence in depth provision against freed peers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: netlink: check for dangling peer via is_dead instead of empty list<br /> <br /> If all peers are removed via wg_peer_remove_all(), rather than setting<br /> peer_list to empty, the peer is added to a temporary list with a head on<br /> the stack of wg_peer_remove_all(). If a netlink dump is resumed and the<br /> cursored peer is one that has been removed via wg_peer_remove_all(), it<br /> will iterate from that peer and then attempt to dump freed peers.<br /> <br /> Fix this by instead checking peer-&gt;is_dead, which was explictly created<br /> for this purpose. Also move up the device_update_lock lockdep assertion,<br /> since reading is_dead relies on that.<br /> <br /> It can be reproduced by a small script like:<br /> <br /> echo "Setting config..."<br /> ip link add dev wg0 type wireguard<br /> wg setconf wg0 /big-config<br /> (<br /> while true; do<br /> echo "Showing config..."<br /> wg showconf wg0 &gt; /dev/null<br /> done<br /> ) &amp;<br /> sleep 4<br /> wg setconf wg0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - Fix nr_cpus