Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: tlv320adcx140: fix null pointer<br /> <br /> The "snd_soc_component" in "adcx140_priv" was only used once but never<br /> set. It was only used for reaching "dev" which is already present in<br /> "adcx140_priv".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: zero non-PI portion of auto integrity buffer<br /> <br /> The auto-generated integrity buffer for writes needs to be fully<br /> initialized before being passed to the underlying block device,<br /> otherwise the uninitialized memory can be read back by userspace or<br /> anyone with physical access to the storage device. If protection<br /> information is generated, that portion of the integrity buffer is<br /> already initialized. The integrity data is also zeroed if PI generation<br /> is disabled via sysfs or the PI tuple size is 0. However, this misses<br /> the case where PI is generated and the PI tuple size is nonzero, but the<br /> metadata size is larger than the PI tuple. In this case, the remainder<br /> ("opaque") of the metadata is left uninitialized.<br /> Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the<br /> metadata is larger than just the PI tuple.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix KMS with 3D on HW version 10<br /> <br /> HW version 10 does not have GB Surfaces so there is no backing buffer for<br /> surface backed FBs. This would result in a nullptr dereference and crash<br /> the driver causing a black screen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: don&amp;#39;t dereference freed ring when removing sideband endpoint<br /> <br /> xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is<br /> running and has a valid transfer ring.<br /> <br /> Lianqin reported a crash during suspend/wake-up stress testing, and<br /> found the cause to be dereferencing a non-existing transfer ring<br /> &amp;#39;ep-&gt;ring&amp;#39; during xhci_sideband_remove_endpoint().<br /> <br /> The endpoint and its ring may be in unknown state if this function<br /> is called after xHCI was reinitialized in resume (lost power), or if<br /> device is being re-enumerated, disconnected or endpoint already dropped.<br /> <br /> Fix this by both removing unnecessary ring access, and by checking<br /> ep-&gt;ring exists before dereferencing it. Also make sure endpoint is<br /> running before attempting to stop it.<br /> <br /> Remove the xhci_initialize_ring_info() call during sideband endpoint<br /> removal as is it only initializes ring structure enqueue, dequeue and<br /> cycle state values to their starting values without changing actual<br /> hardware enqueue, dequeue and cycle state. Leaving them out of sync<br /> is worse than leaving it as it is. The endpoint will get freed in after<br /> this in most usecases.<br /> <br /> If the (audio) class driver want&amp;#39;s to reuse the endpoint after offload<br /> then it is up to the class driver to ensure endpoint is properly set up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix use-after-free in inet6_addr_del().<br /> <br /> syzbot reported use-after-free of inet6_ifaddr in<br /> inet6_addr_del(). [0]<br /> <br /> The cited commit accidentally moved ipv6_del_addr() for<br /> mngtmpaddr before reading its ifp-&gt;flags for temporary<br /> addresses in inet6_addr_del().<br /> <br /> Let&amp;#39;s move ipv6_del_addr() down to fix the UAF.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117<br /> Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593<br /> <br /> CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xcd/0x630 mm/kasan/report.c:482<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:595<br /> inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117<br /> addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181<br /> inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1254<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1375<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f164cf8f749<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749<br /> RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003<br /> RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288<br /> <br /> <br /> Allocated by task 9593:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:397 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120<br /> inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050<br /> addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160<br /> inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1254<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1375<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 6099:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:56<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:77<br /> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584<br /> poison_slab_object mm/kasan/common.c:252 [inline]<br /> __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284<br /> kasan_slab_free include/linux/kasan.h:234 [inline]<br /> slab_free_hook mm/slub.c:2540 [inline]<br /> slab_free_freelist_hook mm/slub.c:2569 [inline]<br /> slab_free_bulk mm/slub.c:6696 [inline]<br /> kmem_cache_free_bulk mm/slub.c:7383 [inline]<br /> kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362<br /> kfree_bulk include/linux/slab.h:830 [inline]<br /> kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523<br /> kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline]<br /> kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801<br /> process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqu<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_gre: make ipgre_header() robust<br /> <br /> Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")<br /> <br /> Over the years, syzbot found many ways to crash the kernel<br /> in ipgre_header() [1].<br /> <br /> This involves team or bonding drivers ability to dynamically<br /> change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len<br /> <br /> In this particular crash mld_newpack() allocated an skb<br /> with a too small reserve/headroom, and by the time mld_sendpack()<br /> was called, syzbot managed to attach an ipgre device.<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0<br /> kernel BUG at net/core/skbuff.c:213 !<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213<br /> Call Trace:<br /> <br /> skb_under_panic net/core/skbuff.c:223 [inline]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897<br /> dev_hard_header include/linux/netdevice.h:3436 [inline]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix device leaks on compat bind and unbind<br /> <br /> Make sure to drop the reference taken when looking up the idxd device as<br /> part of the compat bind and unbind sysfs interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t store mlx5e_priv in mlx5e_dev devlink priv<br /> <br /> mlx5e_priv is an unstable structure that can be memset(0) if profile<br /> attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to<br /> reference the netdev and mdev associated with that struct. Instead,<br /> store netdev directly into mlx5e_dev and get mdev from the containing<br /> mlx5_adev aux device structure.<br /> <br /> This fixes a kernel oops in mlx5e_remove when switchdev mode fails due<br /> to change profile failure.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Failed setting eswitch to offloads.<br /> dmesg:<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> <br /> $ devlink dev reload pci/0000:00:03.0 ==&gt; oops<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000520<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_remove+0x68/0x130<br /> RSP: 0018:ffffc900034838f0 EFLAGS: 00010246<br /> RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10<br /> R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0<br /> R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400<br /> FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> device_release_driver_internal+0x19c/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x160/0x3d0<br /> ? devl_param_driverinit_value_get+0x2d/0x90<br /> mlx5_detach_device+0x89/0xe0<br /> mlx5_unload_one_devl_locked+0x3a/0x70<br /> mlx5_devlink_reload_down+0xc8/0x220<br /> devlink_reload+0x7d/0x260<br /> devlink_nl_reload_doit+0x45b/0x5a0<br /> genl_family_rcv_msg_doit+0xe8/0x140

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts<br /> <br /> Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is<br /> called only when the timer is enabled, we need to call<br /> j1939_session_deactivate_activate_next() if we cancelled the timer.<br /> Otherwise, refcount for j1939_session leaks, which will later appear as<br /> <br /> | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.<br /> <br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec<br /> <br /> Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")<br /> added ttag bounds checking and data_offset<br /> validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate<br /> whether the command&amp;#39;s data structures (cmd-&gt;req.sg and cmd-&gt;iov) have<br /> been properly initialized before processing H2C_DATA PDUs.<br /> <br /> The nvmet_tcp_build_pdu_iovec() function dereferences these pointers<br /> without NULL checks. This can be triggered by sending H2C_DATA PDU<br /> immediately after the ICREQ/ICRESP handshake, before<br /> sending a CONNECT command or NVMe write command.<br /> <br /> Attack vectors that trigger NULL pointer dereferences:<br /> 1. H2C_DATA PDU sent before CONNECT → both pointers NULL<br /> 2. H2C_DATA PDU for READ command → cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL<br /> <br /> The fix validates both cmd-&gt;req.sg and cmd-&gt;iov before calling<br /> nvmet_tcp_build_pdu_iovec(). Both checks are required because:<br /> - Uninitialized commands: both NULL<br /> - READ commands: cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> - WRITE commands: both allocated

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: do not free existing class in qfq_change_class()<br /> <br /> Fixes qfq_change_class() error case.<br /> <br /> cl-&gt;qdisc and cl should only be freed if a new class and qdisc<br /> were allocated, or we risk various UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix crash on profile change rollback failure<br /> <br /> mlx5e_netdev_change_profile can fail to attach a new profile and can<br /> fail to rollback to old profile, in such case, we could end up with a<br /> dangling netdev with a fully reset netdev_priv. A retry to change<br /> profile, e.g. another attempt to call mlx5e_netdev_change_profile via<br /> switchdev mode change, will crash trying to access the now NULL<br /> priv-&gt;mdev.<br /> <br /> This fix allows mlx5e_netdev_change_profile() to handle previous<br /> failures and an empty priv, by not assuming priv is valid.<br /> <br /> Pass netdev and mdev to all flows requiring<br /> mlx5e_netdev_change_profile() and avoid passing priv.<br /> In mlx5e_netdev_change_profile() check if current priv is valid, and if<br /> not, just attach the new profile without trying to access the old one.<br /> <br /> This fixes the following oops, when enabling switchdev mode for the 2nd<br /> time after first time failure:<br /> <br /> ## Enabling switchdev mode first time:<br /> <br /> mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> ^^^^^^^^<br /> mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> <br /> ## retry: Enabling switchdev mode 2nd time:<br /> <br /> mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload<br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_detach_netdev+0x3c/0x90<br /> Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07<br /> RSP: 0018:ffffc90000673890 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000<br /> RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000<br /> R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000<br /> FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> mlx5e_netdev_change_profile+0x45/0xb0<br /> mlx5e_vport_rep_load+0x27b/0x2d0<br /> mlx5_esw_offloads_rep_load+0x72/0xf0<br /> esw_offloads_enable+0x5d0/0x970<br /> mlx5_eswitch_enable_locked+0x349/0x430<br /> ? is_mp_supported+0x57/0xb0<br /> mlx5_devlink_eswitch_mode_set+0x26b/0x430<br /> devlink_nl_eswitch_set_doit+0x6f/0xf0<br /> genl_family_rcv_msg_doit+0xe8/0x140<br /> genl_rcv_msg+0x18b/0x290<br /> ? __pfx_devlink_nl_pre_doit+0x10/0x10<br /> ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10<br /> ? __pfx_devlink_nl_post_doit+0x10/0x10<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x52/0x100<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x282/0x3e0<br /> ? __alloc_skb+0xd6/0x190<br /> netlink_sendmsg+0x1f7/0x430<br /> __sys_sendto+0x213/0x220<br /> ? __sys_recvmsg+0x6a/0xd0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x50/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdfb8495047