Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().<br /> <br /> Brad Spengler reported the list_del() corruption splat in<br /> gtp_net_exit_batch_rtnl(). [0]<br /> <br /> Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket&amp;#39;s netns<br /> dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()<br /> to destroy devices in each netns as done in geneve and ip tunnels.<br /> <br /> However, this could trigger -&gt;dellink() twice for the same device during<br /> -&gt;exit_batch_rtnl().<br /> <br /> Say we have two netns A &amp; B and gtp device B that resides in netns B but<br /> whose UDP socket is in netns A.<br /> <br /> 1. cleanup_net() processes netns A and then B.<br /> <br /> 2. gtp_net_exit_batch_rtnl() finds the device B while iterating<br /> netns A&amp;#39;s gn-&gt;gtp_dev_list and calls -&gt;dellink().<br /> <br /> [ device B is not yet unlinked from netns B<br /> as unregister_netdevice_many() has not been called. ]<br /> <br /> 3. gtp_net_exit_batch_rtnl() finds the device B while iterating<br /> netns B&amp;#39;s for_each_netdev() and calls -&gt;dellink().<br /> <br /> gtp_dellink() cleans up the device&amp;#39;s hash table, unlinks the dev from<br /> gn-&gt;gtp_dev_list, and calls unregister_netdevice_queue().<br /> <br /> Basically, calling gtp_dellink() multiple times is fine unless<br /> CONFIG_DEBUG_LIST is enabled.<br /> <br /> Let&amp;#39;s remove for_each_netdev() in gtp_net_exit_batch_rtnl() and<br /> delegate the destruction to default_device_exit_batch() as done<br /> in bareudp.<br /> <br /> [0]:<br /> list_del corruption, ffff8880aaa62c00-&gt;next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)<br /> kernel BUG at lib/list_debug.c:58!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1<br /> Tainted: [T]=RANDSTRUCT<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58<br /> Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60<br /> RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283<br /> RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054<br /> RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000<br /> RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32<br /> R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4<br /> R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08<br /> RBX: kasan shadow of 0x0<br /> RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554<br /> RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58<br /> RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71<br /> RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]<br /> RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]<br /> R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]<br /> R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]<br /> R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]<br /> FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0<br /> Stack:<br /> 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00<br /> ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005<br /> 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d<br /> Call Trace:<br /> <br /> [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28<br /> [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28<br /> [] list_del include/linux/list.h:262 [inl<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sockmap, vsock: For connectible sockets allow only connected<br /> <br /> sockmap expects all vsocks to have a transport assigned, which is expressed<br /> in vsock_proto::psock_update_sk_prot(). However, there is an edge case<br /> where an unconnected (connectible) socket may lose its previously assigned<br /> transport. This is handled with a NULL check in the vsock/BPF recv path.<br /> <br /> Another design detail is that listening vsocks are not supposed to have any<br /> transport assigned at all. Which implies they are not supported by the<br /> sockmap. But this is complicated by the fact that a socket, before<br /> switching to TCP_LISTEN, may have had some transport assigned during a<br /> failed connect() attempt. Hence, we may end up with a listening vsock in a<br /> sockmap, which blows up quickly:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]<br /> CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+<br /> Workqueue: vsock-loopback vsock_loopback_work<br /> RIP: 0010:vsock_read_skb+0x4b/0x90<br /> Call Trace:<br /> sk_psock_verdict_data_ready+0xa4/0x2e0<br /> virtio_transport_recv_pkt+0x1ca8/0x2acc<br /> vsock_loopback_work+0x27d/0x3f0<br /> process_one_work+0x846/0x1420<br /> worker_thread+0x5b3/0xf80<br /> kthread+0x35a/0x700<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> For connectible sockets, instead of relying solely on the state of<br /> vsk-&gt;transport, tell sockmap to only allow those representing established<br /> connections. This aligns with the behaviour for AF_INET and AF_UNIX.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ism: add release function for struct device<br /> <br /> According to device_release() in /drivers/base/core.c,<br /> a device without a release function is a broken device<br /> and must be fixed.<br /> <br /> The current code directly frees the device after calling device_add()<br /> without waiting for other kernel parts to release their references.<br /> Thus, a reference could still be held to a struct device,<br /> e.g., by sysfs, leading to potential use-after-free<br /> issues if a proper release function is not set.

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.