Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape<br /> <br /> For raid456, if reshape is still in progress, then IO across reshape<br /> position will wait for reshape to make progress. However, for dm-raid,<br /> in following cases reshape will never make progress hence IO will hang:<br /> <br /> 1) the array is read-only;<br /> 2) MD_RECOVERY_WAIT is set;<br /> 3) MD_RECOVERY_FROZEN is set;<br /> <br /> After commit c467e97f079f ("md/raid6: use valid sector values to determine<br /> if an I/O should wait on the reshape") fix the problem that IO across<br /> reshape position doesn&amp;#39;t wait for reshape, the dm-raid test<br /> shell/lvconvert-raid-reshape.sh start to hang:<br /> <br /> [root@fedora ~]# cat /proc/979/stack<br /> [] wait_woken+0x7d/0x90<br /> [] raid5_make_request+0x929/0x1d70 [raid456]<br /> [] md_handle_request+0xc2/0x3b0 [md_mod]<br /> [] raid_map+0x2c/0x50 [dm_raid]<br /> [] __map_bio+0x251/0x380 [dm_mod]<br /> [] dm_submit_bio+0x1f0/0x760 [dm_mod]<br /> [] __submit_bio+0xc2/0x1c0<br /> [] submit_bio_noacct_nocheck+0x17f/0x450<br /> [] submit_bio_noacct+0x2bc/0x780<br /> [] submit_bio+0x70/0xc0<br /> [] mpage_readahead+0x169/0x1f0<br /> [] blkdev_readahead+0x18/0x30<br /> [] read_pages+0x7c/0x3b0<br /> [] page_cache_ra_unbounded+0x1ab/0x280<br /> [] force_page_cache_ra+0x9e/0x130<br /> [] page_cache_sync_ra+0x3b/0x110<br /> [] filemap_get_pages+0x143/0xa30<br /> [] filemap_read+0xdc/0x4b0<br /> [] blkdev_read_iter+0x75/0x200<br /> [] vfs_read+0x272/0x460<br /> [] ksys_read+0x7a/0x170<br /> [] __x64_sys_read+0x1c/0x30<br /> [] do_syscall_64+0xc6/0x230<br /> [] entry_SYSCALL_64_after_hwframe+0x6c/0x74<br /> <br /> This is because reshape can&amp;#39;t make progress.<br /> <br /> For md/raid, the problem doesn&amp;#39;t exist because register new sync_thread<br /> doesn&amp;#39;t rely on the IO to be done any more:<br /> <br /> 1) If array is read-only, it can switch to read-write by ioctl/sysfs;<br /> 2) md/raid never set MD_RECOVERY_WAIT;<br /> 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn&amp;#39;t hold<br /> &amp;#39;reconfig_mutex&amp;#39;, hence it can be cleared and reshape can continue by<br /> sysfs api &amp;#39;sync_action&amp;#39;.<br /> <br /> However, I&amp;#39;m not sure yet how to avoid the problem in dm-raid yet. This<br /> patch on the one hand make sure raid_message() can&amp;#39;t change<br /> sync_thread() through raid_message() after presuspend(), on the other<br /> hand detect the above 3 cases before wait for IO do be done in<br /> dm_suspend(), and let dm-raid requeue those IO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3-am62: fix module unload/reload behavior<br /> <br /> As runtime PM is enabled, the module can be runtime<br /> suspended when .remove() is called.<br /> <br /> Do a pm_runtime_get_sync() to make sure module is active<br /> before doing any register operations.<br /> <br /> Doing a pm_runtime_put_sync() should disable the refclk<br /> so no need to disable it again.<br /> <br /> Fixes the below warning at module removel.<br /> <br /> [ 39.705310] ------------[ cut here ]------------<br /> [ 39.710004] clk:162:3 already disabled<br /> [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8<br /> <br /> We called of_platform_populate() in .probe() so call the<br /> cleanup function of_platform_depopulate() in .remove().<br /> Get rid of the now unnnecessary dwc3_ti_remove_core().<br /> Without this, module re-load doesn&amp;#39;t work properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Add error handling in xhci_map_urb_for_dma<br /> <br /> Currently xhci_map_urb_for_dma() creates a temporary buffer and copies<br /> the SG list to the new linear buffer. But if the kzalloc_node() fails,<br /> then the following sg_pcopy_to_buffer() can lead to crash since it<br /> tries to memcpy to NULL pointer.<br /> <br /> So return -ENOMEM if kzalloc returns null pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays<br /> <br /> The frequency table arrays are supposed to be terminated with an<br /> empty element. Add such entry to the end of the arrays where it<br /> is missing in order to avoid possible out-of-bound access when<br /> the table is traversed by functions like qcom_find_freq() or<br /> qcom_find_freq_floor().<br /> <br /> Only compile tested.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays<br /> <br /> The frequency table arrays are supposed to be terminated with an<br /> empty element. Add such entry to the end of the arrays where it<br /> is missing in order to avoid possible out-of-bound access when<br /> the table is traversed by functions like qcom_find_freq() or<br /> qcom_find_freq_floor().<br /> <br /> Only compile tested.

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 /> 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 /> 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 /> 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.