Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: fix error handling causing NULL dereference<br /> <br /> tcf_exts_miss_cookie_base_alloc() calls xa_alloc_cyclic() which can<br /> return 1 if the allocation succeeded after wrapping. This was treated as<br /> an error, with value 1 returned to caller tcf_exts_init_ex() which sets<br /> exts-&gt;actions to NULL and returns 1 to caller fl_change().<br /> <br /> fl_change() treats err == 1 as success, calling tcf_exts_validate_ex()<br /> which calls tcf_action_init() with exts-&gt;actions as argument, where it<br /> is dereferenced.<br /> <br /> Example trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> CPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el9_5.x86_64 #1<br /> RIP: 0010:tcf_action_init+0x1f8/0x2c0<br /> Call Trace:<br /> tcf_action_init+0x1f8/0x2c0<br /> tcf_exts_validate_ex+0x175/0x190<br /> fl_change+0x537/0x1120 [cls_flower]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/zswap: fix inconsistency when zswap_store_page() fails<br /> <br /> Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()")<br /> skips charging any zswap entries when it failed to zswap the entire folio.<br /> <br /> However, when some base pages are zswapped but it failed to zswap the<br /> entire folio, the zswap operation is rolled back. When freeing zswap<br /> entries for those pages, zswap_entry_free() uncharges the zswap entries<br /> that were not previously charged, causing zswap charging to become<br /> inconsistent.<br /> <br /> This inconsistency triggers two warnings with following steps:<br /> # On a machine with 64GiB of RAM and 36GiB of zswap<br /> $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng<br /> $ sudo reboot<br /> <br /> The two warnings are:<br /> in mm/memcontrol.c:163, function obj_cgroup_release():<br /> WARN_ON_ONCE(nr_bytes &amp; (PAGE_SIZE - 1));<br /> <br /> in mm/page_counter.c:60, function page_counter_cancel():<br /> if (WARN_ONCE(new

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: avoid holding freeze_mutex during mmap operation<br /> <br /> We use map-&gt;freeze_mutex to prevent races between map_freeze() and<br /> memory mapping BPF map contents with writable permissions. The way we<br /> naively do this means we&amp;#39;ll hold freeze_mutex for entire duration of all<br /> the mm and VMA manipulations, which is completely unnecessary. This can<br /> potentially also lead to deadlocks, as reported by syzbot in [0].<br /> <br /> So, instead, hold freeze_mutex only during writeability checks, bump<br /> (proactively) "write active" count for the map, unlock the mutex and<br /> proceed with mmap logic. And only if something went wrong during mmap<br /> logic, then undo that "write active" counter increment.<br /> <br /> [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Don&amp;#39;t reference skb after sending to VIOS<br /> <br /> Previously, after successfully flushing the xmit buffer to VIOS,<br /> the tx_bytes stat was incremented by the length of the skb.<br /> <br /> It is invalid to access the skb memory after sending the buffer to<br /> the VIOS because, at any point after sending, the VIOS can trigger<br /> an interrupt to free this memory. A race between reading skb-&gt;len<br /> and freeing the skb is possible (especially during LPM) and will<br /> result in use-after-free:<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]<br /> Read of size 4 at addr c00000024eb48a70 by task hxecom/14495<br /> <br /> Call Trace:<br /> [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)<br /> [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0<br /> [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8<br /> [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0<br /> [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]<br /> [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358<br /> <br /> Freed by task 0:<br /> kasan_save_stack+0x34/0x68<br /> kasan_save_track+0x2c/0x50<br /> kasan_save_free_info+0x64/0x108<br /> __kasan_mempool_poison_object+0x148/0x2d4<br /> napi_skb_cache_put+0x5c/0x194<br /> net_tx_action+0x154/0x5b8<br /> handle_softirqs+0x20c/0x60c<br /> do_softirq_own_stack+0x6c/0x88<br /> <br /> The buggy address belongs to the object at c00000024eb48a00 which<br /> belongs to the cache skbuff_head_cache of size 224<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: Fix use-after-free in geneve_find_dev().<br /> <br /> syzkaller reported a use-after-free in geneve_find_dev() [0]<br /> without repro.<br /> <br /> geneve_configure() links struct geneve_dev.next to<br /> net_generic(net, geneve_net_id)-&gt;geneve_list.<br /> <br /> The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,<br /> IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.<br /> <br /> When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally<br /> calls unregister_netdevice_queue() for each dev in the netns,<br /> and later the dev is freed.<br /> <br /> However, its geneve_dev.next is still linked to the backend UDP<br /> socket netns.<br /> <br /> Then, use-after-free will occur when another geneve dev is created<br /> in the netns.<br /> <br /> Let&amp;#39;s call geneve_dellink() instead in geneve_destroy_tunnels().<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]<br /> BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343<br /> Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441<br /> <br /> CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x16c/0x6f0 mm/kasan/report.c:489<br /> kasan_report+0xc0/0x120 mm/kasan/report.c:602<br /> __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379<br /> geneve_find_dev drivers/net/geneve.c:1295 [inline]<br /> geneve_configure+0x234/0x858 drivers/net/geneve.c:1343<br /> geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634<br /> rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795<br /> __rtnl_newlink net/core/rtnetlink.c:3906 [inline]<br /> rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021<br /> rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911<br /> netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543<br /> rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]<br /> netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348<br /> netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892<br /> sock_sendmsg_nosec net/socket.c:713 [inline]<br /> __sock_sendmsg net/socket.c:728 [inline]<br /> ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568<br /> ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622<br /> __sys_sendmsg net/socket.c:2654 [inline]<br /> __do_sys_sendmsg net/socket.c:2659 [inline]<br /> __se_sys_sendmsg net/socket.c:2657 [inline]<br /> __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762<br /> el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600<br /> <br /> Allocated by task 13247:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x68 mm/kasan/common.c:68<br /> kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4298 [inline]<br /> __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304<br /> __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645<br /> alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470<br /> rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604<br /> rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780<br /> __rtnl_newlink net/core/rtnetlink.c:3906 [inline]<br /> rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021<br /> rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911<br /> netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543<br /> rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938<br /> netlink_unicast_kernel net/netlink/af_n<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: f_midi: f_midi_complete to call queue_work<br /> <br /> When using USB MIDI, a lock is attempted to be acquired twice through a<br /> re-entrant call to f_midi_transmit, causing a deadlock.<br /> <br /> Fix it by using queue_work() to schedule the inner f_midi_transmit() via<br /> a high priority work queue from the completion handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()<br /> <br /> The nullity of sps-&gt;cstream should be checked similarly as it is done in<br /> sof_set_stream_data_offset() function.<br /> Assuming that it is not NULL if sps-&gt;stream is NULL is incorrect and can<br /> lead to NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Use spin_lock_irqsave() in interruptible context<br /> <br /> spin_lock/unlock() functions used in interrupt contexts could<br /> result in a deadlock, as seen in GitLab issue #13399,<br /> which occurs when interrupt comes in while holding a lock.<br /> <br /> Try to remedy the problem by saving irq state before spin lock<br /> acquisition.<br /> <br /> v2: add irqs&amp;#39; state save/restore calls to all locks/unlocks in<br /> signal_irq_work() execution (Maciej)<br /> <br /> v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead<br /> of other lock/unlock calls and add Fixes and Cc tags (Tvrtko);<br /> change title and commit message<br /> <br /> (cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: Fix crash when a namespace is disabled<br /> <br /> The namespace percpu counter protects pending I/O, and we can<br /> only safely diable the namespace once the counter drop to zero.<br /> Otherwise we end up with a crash when running blktests/nvme/058<br /> (eg for loop transport):<br /> <br /> [ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232<br /> [ 2352.930438] [ T53909] Tainted: [W]=WARN<br /> [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]<br /> [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180<br /> <br /> as the queue is already torn down when calling submit_bio();<br /> <br /> So we need to init the percpu counter in nvmet_ns_enable(), and<br /> wait for it to drop to zero in nvmet_ns_disable() to avoid having<br /> I/O pending after the namespace has been disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix softlockup in arena_map_free on 64k page kernel<br /> <br /> On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,<br /> arena_htab tests cause a segmentation fault and soft lockup.<br /> The same failure is not observed with 4k pages on aarch64.<br /> <br /> It turns out arena_map_free() is calling<br /> apply_to_existing_page_range() with the address returned by<br /> bpf_arena_get_kern_vm_start(). If this address is not page-aligned<br /> the code ends up calling apply_to_pte_range() with that unaligned<br /> address causing soft lockup.<br /> <br /> Fix it by round up GUARD_SZ to PAGE_SIZE

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Add rx_skb of kfree_skb to raw_tp_null_args[].<br /> <br /> Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0]<br /> in trace_kfree_skb if the prog does not check if rx_sk is NULL.<br /> <br /> Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") added<br /> rx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL.<br /> <br /> Let&amp;#39;s add kfree_skb to raw_tp_null_args[] to let the BPF verifier<br /> validate such a prog and prevent the issue.<br /> <br /> Now we fail to load such a prog:<br /> <br /> libbpf: prog &amp;#39;drop&amp;#39;: -- BEGIN PROG LOAD LOG --<br /> 0: R1=ctx() R10=fp0<br /> ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21<br /> 0: (79) r3 = *(u64 *)(r1 +24)<br /> func &amp;#39;kfree_skb&amp;#39; arg3 has btf_id 5253 type STRUCT &amp;#39;sock&amp;#39;<br /> 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1)<br /> ; bpf_printk("sk: %d, %d\n", sk, sk-&gt;__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24<br /> 1: (69) r4 = *(u16 *)(r3 +16)<br /> R3 invalid mem access &amp;#39;trusted_ptr_or_null_&amp;#39;<br /> processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0<br /> -- END PROG LOAD LOG --<br /> <br /> Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tp<br /> arguments with PTR_MAYBE_NULL").<br /> <br /> [0]:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> PREEMPT SMP<br /> RIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x148/0x420<br /> ? search_bpf_extables+0x5b/0x70<br /> ? fixup_exception+0x27/0x2c0<br /> ? exc_page_fault+0x75/0x170<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d<br /> bpf_trace_run4+0x68/0xd0<br /> ? unix_stream_connect+0x1f4/0x6f0<br /> sk_skb_reason_drop+0x90/0x120<br /> unix_stream_connect+0x1f4/0x6f0<br /> __sys_connect+0x7f/0xb0<br /> __x64_sys_connect+0x14/0x20<br /> do_syscall_64+0x47/0xc30<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()<br /> <br /> Add check for the return value of nfp_app_ctrl_msg_alloc() in<br /> nfp_bpf_cmsg_alloc() to prevent null pointer dereference.