Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Clear napi-&gt;skb before dev_kfree_skb_any()<br /> <br /> gve_rx_free_skb incorrectly leaves napi-&gt;skb referencing an skb after it<br /> is freed with dev_kfree_skb_any(). This can result in a subsequent call<br /> to napi_get_frags returning a dangling pointer.<br /> <br /> Fix this by clearing napi-&gt;skb before the skb is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix d_parent walk<br /> <br /> The WARN_ON_ONCE() in collect_domain_accesses() can be triggered when<br /> trying to link a root mount point. This cannot work in practice because<br /> this directory is mounted, but the VFS check is done after the call to<br /> security_path_link().<br /> <br /> Do not use source directory&amp;#39;s d_parent when the source directory is the<br /> mount point.<br /> <br /> [mic: Fix commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: Fix tainted pointer delete is case of region creation fail<br /> <br /> In case of region creation fail in ipc_devlink_create_region(), previously<br /> created regions delete process starts from tainted pointer which actually<br /> holds error code value.<br /> Fix this bug by decreasing region index before delete.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix tainted pointer delete is case of flow rules creation fail<br /> <br /> In case of flow rule creation fail in mlx5_lag_create_port_sel_table(),<br /> instead of previously created rules, the tainted pointer is deleted<br /> deveral times.<br /> Fix this bug by using correct flow rules pointers.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t read past the mfuart notifcation<br /> <br /> In case the firmware sends a notification that claims it has more data<br /> than it has, we will read past that was allocated for the notification.<br /> Remove the print of the buffer, we won&amp;#39;t see it by default. If needed,<br /> we can see the content with tracing.<br /> <br /> This was reported by KFENCE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects<br /> <br /> The hwmp code use objects of type mesh_preq_queue, added to a list in<br /> ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath<br /> gets deleted, ex mesh interface is removed, the entries in that list will<br /> never get cleaned. Fix this by flushing all corresponding items of the<br /> preq_queue in mesh_path_flush_pending().<br /> <br /> This should take care of KASAN reports like this:<br /> <br /> unreferenced object 0xffff00000668d800 (size 128):<br /> comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)<br /> hex dump (first 32 bytes):<br /> 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....<br /> 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;...........<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e0/0x35c<br /> [] kmalloc_trace+0x34/0x80<br /> [] mesh_queue_preq+0x44/0x2a8<br /> [] mesh_nexthop_resolve+0x198/0x19c<br /> [] ieee80211_xmit+0x1d0/0x1f4<br /> [] __ieee80211_subif_start_xmit+0x30c/0x764<br /> [] ieee80211_subif_start_xmit+0x9c/0x7a4<br /> [] dev_hard_start_xmit+0x174/0x440<br /> [] __dev_queue_xmit+0xe24/0x111c<br /> [] batadv_send_skb_packet+0x180/0x1e4<br /> [] batadv_v_elp_periodic_work+0x2f4/0x508<br /> [] process_one_work+0x4b8/0xa1c<br /> [] worker_thread+0x9c/0x634<br /> [] kthread+0x1bc/0x1c4<br /> [] ret_from_fork+0x10/0x20<br /> unreferenced object 0xffff000009051f00 (size 128):<br /> comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)<br /> hex dump (first 32 bytes):<br /> 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....<br /> 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6&amp;#39;.......Xy.....<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e0/0x35c<br /> [] kmalloc_trace+0x34/0x80<br /> [] mesh_queue_preq+0x44/0x2a8<br /> [] mesh_nexthop_resolve+0x198/0x19c<br /> [] ieee80211_xmit+0x1d0/0x1f4<br /> [] __ieee80211_subif_start_xmit+0x30c/0x764<br /> [] ieee80211_subif_start_xmit+0x9c/0x7a4<br /> [] dev_hard_start_xmit+0x174/0x440<br /> [] __dev_queue_xmit+0xe24/0x111c<br /> [] batadv_send_skb_packet+0x180/0x1e4<br /> [] batadv_v_elp_periodic_work+0x2f4/0x508<br /> [] process_one_work+0x4b8/0xa1c<br /> [] worker_thread+0x9c/0x634<br /> [] kthread+0x1bc/0x1c4<br /> [] ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix races between hole punching and AIO+DIO<br /> <br /> After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",<br /> fstests/generic/300 become from always failed to sometimes failed:<br /> <br /> ========================================================================<br /> [ 473.293420 ] run fstests generic/300<br /> <br /> [ 475.296983 ] JBD2: Ignoring recovery information on journal<br /> [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.<br /> [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found<br /> [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.<br /> [ 494.292018 ] OCFS2: File system is now read-only.<br /> [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30<br /> [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3<br /> fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072<br /> =========================================================================<br /> <br /> In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten<br /> extents to a list. extents are also inserted into extent tree in<br /> ocfs2_write_begin_nolock. Then another thread call fallocate to puch a<br /> hole at one of the unwritten extent. The extent at cpos was removed by<br /> ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list<br /> found there is no such extent at the cpos.<br /> <br /> T1 T2 T3<br /> inode lock<br /> ...<br /> insert extents<br /> ...<br /> inode unlock<br /> ocfs2_fallocate<br /> __ocfs2_change_file_space<br /> inode lock<br /> lock ip_alloc_sem<br /> ocfs2_remove_inode_range inode<br /> ocfs2_remove_btree_range<br /> ocfs2_remove_extent<br /> ^---remove the extent at cpos 78723<br /> ...<br /> unlock ip_alloc_sem<br /> inode unlock<br /> ocfs2_dio_end_io<br /> ocfs2_dio_end_io_write<br /> lock ip_alloc_sem<br /> ocfs2_mark_extent_written<br /> ocfs2_change_extent_flag<br /> ocfs2_search_extent_list<br /> ^---failed to find extent<br /> ...<br /> unlock ip_alloc_sem<br /> <br /> In most filesystems, fallocate is not compatible with racing with AIO+DIO,<br /> so fix it by adding to wait for all dio before fallocate/punch_hole like<br /> ext4.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: don&amp;#39;t lock while !TASK_RUNNING<br /> <br /> There is a report of io_rsrc_ref_quiesce() locking a mutex while not<br /> TASK_RUNNING, which is due to forgetting restoring the state back after<br /> io_run_task_work_sig() and attempts to break out of the waiting loop.<br /> <br /> do not call blocking ops when !TASK_RUNNING; state=1 set at<br /> [] prepare_to_wait+0xa4/0x380<br /> kernel/sched/wait.c:237<br /> WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099<br /> __might_sleep+0x114/0x160 kernel/sched/core.c:10099<br /> RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099<br /> Call Trace:<br /> <br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752<br /> io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253<br /> io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799<br /> __io_uring_register io_uring/register.c:424 [inline]<br /> __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmxnet3: disable rx data ring on dma allocation failure<br /> <br /> When vmxnet3_rq_create() fails to allocate memory for rq-&gt;data_ring.base,<br /> the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset<br /> rq-&gt;data_ring.desc_size for the data ring that failed, which presumably<br /> causes the hypervisor to reference it on packet reception.<br /> <br /> To fix this bug, rq-&gt;data_ring.desc_size needs to be set to 0 to tell<br /> the hypervisor to disable this feature.<br /> <br /> [ 95.436876] kernel BUG at net/core/skbuff.c:207!<br /> [ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1<br /> [ 95.441558] Hardware name: VMware, Inc. VMware Virtual<br /> Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018<br /> [ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f<br /> [ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50<br /> ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9<br /> ff 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24<br /> [ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246<br /> [ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f<br /> [ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f<br /> [ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60<br /> [ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000<br /> [ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0<br /> [ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000<br /> [ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0<br /> [ 95.459791] Call Trace:<br /> [ 95.460515] <br /> [ 95.461180] ? __die_body.cold+0x19/0x27<br /> [ 95.462150] ? die+0x2e/0x50<br /> [ 95.462976] ? do_trap+0xca/0x110<br /> [ 95.463973] ? do_error_trap+0x6a/0x90<br /> [ 95.464966] ? skb_panic+0x4d/0x4f<br /> [ 95.465901] ? exc_invalid_op+0x50/0x70<br /> [ 95.466849] ? skb_panic+0x4d/0x4f<br /> [ 95.467718] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 95.468758] ? skb_panic+0x4d/0x4f<br /> [ 95.469655] skb_put.cold+0x10/0x10<br /> [ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]<br /> [ 95.471853] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]<br /> [ 95.473185] __napi_poll+0x2b/0x160<br /> [ 95.474145] net_rx_action+0x2c6/0x3b0<br /> [ 95.475115] handle_softirqs+0xe7/0x2a0<br /> [ 95.476122] __irq_exit_rcu+0x97/0xb0<br /> [ 95.477109] common_interrupt+0x85/0xa0<br /> [ 95.478102] <br /> [ 95.478846] <br /> [ 95.479603] asm_common_interrupt+0x26/0x40<br /> [ 95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20<br /> [ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90<br /> [ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246<br /> [ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000<br /> [ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001<br /> [ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3<br /> [ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260<br /> [ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000<br /> [ 95.495035] acpi_safe_halt+0x14/0x20<br /> [ 95.496127] acpi_idle_do_entry+0x2f/0x50<br /> [ 95.497221] acpi_idle_enter+0x7f/0xd0<br /> [ 95.498272] cpuidle_enter_state+0x81/0x420<br /> [ 95.499375] cpuidle_enter+0x2d/0x40<br /> [ 95.500400] do_idle+0x1e5/0x240<br /> [ 95.501385] cpu_startup_entry+0x29/0x30<br /> [ 95.502422] start_secondary+0x11c/0x140<br /> [ 95.503454] common_startup_64+0x13e/0x141<br /> [ 95.504466] <br /> [ 95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4<br /> nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6<br /> nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix request.queuelist usage in flush<br /> <br /> Friedrich Weber reported a kernel crash problem and bisected to commit<br /> 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine").<br /> <br /> The root cause is that we use "list_move_tail(&amp;rq-&gt;queuelist, pending)"<br /> in the PREFLUSH/POSTFLUSH sequences. But rq-&gt;queuelist.next == xxx since<br /> it&amp;#39;s popped out from plug-&gt;cached_rq in __blk_mq_alloc_requests_batch().<br /> We don&amp;#39;t initialize its queuelist just for this first request, although<br /> the queuelist of all later popped requests will be initialized.<br /> <br /> Fix it by changing to use "list_add_tail(&amp;rq-&gt;queuelist, pending)" so<br /> rq-&gt;queuelist doesn&amp;#39;t need to be initialized. It should be ok since rq<br /> can&amp;#39;t be on any list when PREFLUSH or POSTFLUSH, has no move actually.<br /> <br /> Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in<br /> flush state machine") also has another requirement that no drivers would<br /> touch rq-&gt;queuelist after blk_mq_end_request() since we will reuse it to<br /> add rq to the post-flush pending list in POSTFLUSH. If this is not true,<br /> we will have to revert that commit IMHO.<br /> <br /> This updated version adds "list_del_init(&amp;rq-&gt;queuelist)" in flush rq<br /> callback since the dm layer may submit request of a weird invalid format<br /> (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add<br /> if without this "list_del_init(&amp;rq-&gt;queuelist)". The weird invalid format<br /> problem should be fixed in dm layer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: don&amp;#39;t attempt to schedule hpd_work on headless cards<br /> <br /> If the card doesn&amp;#39;t have display hardware, hpd_work and hpd_lock are<br /> left uninitialized which causes BUG when attempting to schedule hpd_work<br /> on runtime PM resume.<br /> <br /> Fix it by adding headless flag to DRM and skip any hpd if it&amp;#39;s set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: validate HE operation element parsing<br /> <br /> Validate that the HE operation element has the correct<br /> length before parsing it.