Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix error recovery in macvlan_common_newlink()<br /> <br /> valis provided a nice repro to crash the kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> He also gave a very detailed analysis:<br /> <br /> <br /> <br /> The issue is triggered when a new macvlan link is created with<br /> MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or<br /> MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan<br /> port and register_netdevice() called from macvlan_common_newlink()<br /> fails (e.g. because of the invalid link name).<br /> <br /> In this case macvlan_hash_add_source is called from<br /> macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> This adds a reference to vlan to the port&amp;#39;s vlan_source_hash using<br /> macvlan_source_entry.<br /> <br /> vlan is a pointer to the priv data of the link that is being created.<br /> <br /> When register_netdevice() fails, the error is returned from<br /> macvlan_newlink() to rtnl_newlink_create():<br /> <br /> if (ops-&gt;newlink)<br /> err = ops-&gt;newlink(dev, &amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix memory leak in smb2_open_file()<br /> <br /> Reproducer:<br /> <br /> 1. server: directories are exported read-only<br /> 2. client: mount -t cifs //${server_ip}/export /mnt<br /> 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. client: umount /mnt<br /> 5. client: sleep 1<br /> 6. client: modprobe -r cifs<br /> <br /> The error message is as follows:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Call Trace:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Prevent excessive number of frames<br /> <br /> In this case, the user constructed the parameters with maxpacksize 40<br /> for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer<br /> size for each data URB is maxpacksize * packets, which in this example<br /> is 40 * 6 = 240; When the user performs a write operation to send audio<br /> data into the ALSA PCM playback stream, the calculated number of frames<br /> is packsize[0] * packets = 264, which exceeds the allocated URB buffer<br /> size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].<br /> <br /> Added a check for the number of single data URB frames when calculating<br /> the number of frames to prevent [1].<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506<br /> Call Trace:<br /> copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611<br /> prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero<br /> <br /> The driver allocates arrays for ports, FDBs, and filter blocks using<br /> kcalloc() with ethsw-&gt;sw_attr.num_ifs as the element count. When the<br /> device reports zero interfaces (either due to hardware configuration<br /> or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)<br /> instead of NULL.<br /> <br /> Later in dpaa2_switch_probe(), the NAPI initialization unconditionally<br /> accesses ethsw-&gt;ports[0]-&gt;netdev, which attempts to dereference<br /> ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.<br /> <br /> Add a check to ensure num_ifs is greater than zero after retrieving<br /> device attributes. This prevents the zero-sized allocations and<br /> subsequent invalid pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue<br /> <br /> Commit 1767bb2d47b7 ("ipv6: mcast: Don&amp;#39;t hold RTNL for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this<br /> change triggered the following call trace on my BeagleBone Black board:<br /> WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: assertion failed at net/8021q/vlan_core.c (236)<br /> Modules linked in:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Hardware name: Generic AM33XX (Flattened Device Tree)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x28/0x2c<br /> show_stack from dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl from __warn+0xb8/0x11c<br /> __warn from warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt from vlan_for_each+0x120/0x124<br /> vlan_for_each from cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88<br /> __dev_mc_add from igmp6_group_added+0x84/0xec<br /> igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt from __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt from ret_fast_syscall+0x0/0x5<br /> <br /> This trace occurs because vlan_for_each() is called within<br /> cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.<br /> Since modifying vlan_for_each() to operate without the RTNL lock is not<br /> straightforward, and because ndo_set_rx_mode() is invoked both with and<br /> without the RTNL lock across different code paths, simply adding<br /> rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.<br /> <br /> To resolve this issue, we opt to execute the actual processing within<br /> a work queue, following the approach used by the icssg-prueth driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer<br /> <br /> The curr_xfer field is read by the IRQ handler without holding the lock<br /> to check if a transfer is in progress. When clearing curr_xfer in the<br /> combined sequence transfer loop, protect it with the spinlock to prevent<br /> a race with the interrupt handler.<br /> <br /> Protect the curr_xfer clearing at the exit path of<br /> tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race<br /> with the interrupt handler that reads this field.<br /> <br /> Without this protection, the IRQ handler could read a partially updated<br /> curr_xfer value, leading to NULL pointer dereference or use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> linkwatch: use __dev_put() in callers to prevent UAF<br /> <br /> After linkwatch_do_dev() calls __dev_put() to release the linkwatch<br /> reference, the device refcount may drop to 1. At this point,<br /> netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an<br /> empty list and returns without blocking), wait for the refcount to<br /> become 1 via netdev_wait_allrefs_any(), and then free the device<br /> via kobject_put().<br /> <br /> This creates a use-after-free when __linkwatch_run_queue() tries to<br /> call netdev_unlock_ops() on the already-freed device.<br /> <br /> Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in<br /> netdev_run_todo() before kobject_put() would not work, because<br /> netdev_lock_ops() is conditional - it only locks when<br /> netdev_need_ops_lock() returns true. If the device doesn&amp;#39;t require<br /> ops_lock, linkwatch won&amp;#39;t hold any lock, and netdev_run_todo()<br /> acquiring the lock won&amp;#39;t provide synchronization.<br /> <br /> Fix this by moving __dev_put() from linkwatch_do_dev() to its<br /> callers. The device reference logically pairs with de-listing the<br /> device, so it&amp;#39;s reasonable for the caller that did the de-listing<br /> to release it. This allows placing __dev_put() after all device<br /> accesses are complete, preventing UAF.<br /> <br /> The bug can be reproduced by adding mdelay(2000) after<br /> linkwatch_do_dev() in __linkwatch_run_queue(), then running:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()<br /> <br /> In iscsit_dec_session_usage_count(), the function calls complete() while<br /> holding the sess-&gt;session_usage_lock. Similar to the connection usage count<br /> logic, the waiter signaled by complete() (e.g., in the session release<br /> path) may wake up and free the iscsit_session structure immediately.<br /> <br /> This creates a race condition where the current thread may attempt to<br /> execute spin_unlock_bh() on a session structure that has already been<br /> deallocated, resulting in a KASAN slab-use-after-free.<br /> <br /> To resolve this, release the session_usage_lock before calling complete()<br /> to ensure all dereferences of the sess pointer are finished before the<br /> waiter is allowed to proceed with deallocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/dmem: avoid pool UAF<br /> <br /> An UAF issue was observed:<br /> <br /> BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150<br /> Write of size 8 at addr ffff888106715440 by task insmod/527<br /> <br /> CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11<br /> Tainted: [O]=OOT_MODULE<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> kasan_report+0xca/0x100<br /> kasan_check_range+0x39/0x1c0<br /> page_counter_uncharge+0x65/0x150<br /> dmem_cgroup_uncharge+0x1f/0x260<br /> <br /> Allocated by task 527:<br /> <br /> Freed by task 0:<br /> <br /> The buggy address belongs to the object at ffff888106715400<br /> which belongs to the cache kmalloc-512 of size 512<br /> The buggy address is located 64 bytes inside of<br /> freed 512-byte region [ffff888106715400, ffff888106715600)<br /> <br /> The buggy address belongs to the physical page:<br /> <br /> Memory state around the buggy address:<br /> ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> <br /> The issue occurs because a pool can still be held by a caller after its<br /> associated memory region is unregistered. The current implementation frees<br /> the pool even if users still hold references to it (e.g., before uncharge<br /> operations complete).<br /> <br /> This patch adds a reference counter to each pool, ensuring that a pool is<br /> only freed when its reference count drops to zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t clobber irqfd routing type when deassigning irqfd<br /> <br /> When deassigning a KVM_IRQFD, don&amp;#39;t clobber the irqfd&amp;#39;s copy of the IRQ&amp;#39;s<br /> routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86<br /> and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to<br /> handle a concurrent routing update, verify that the irqfd is still active<br /> before consuming the routing information. As evidenced by the x86 and<br /> arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),<br /> clobbering the entry type without notifying arch code is surprising and<br /> error prone.<br /> <br /> As a bonus, checking that the irqfd is active provides a convenient<br /> location for documenting _why_ KVM must not consume the routing entry for<br /> an irqfd that is in the process of being deassigned: once the irqfd is<br /> deleted from the list (which happens *before* the eventfd is detached), it<br /> will no longer receive updates via kvm_irq_routing_update(), and so KVM<br /> could deliver an event using stale routing information (relative to<br /> KVM_SET_GSI_ROUTING returning to userspace).<br /> <br /> As an even better bonus, explicitly checking for the irqfd being active<br /> fixes a similar bug to the one the clobbering is trying to prevent: if an<br /> irqfd is deactivated, and then its routing is changed,<br /> kvm_irq_routing_update() won&amp;#39;t invoke kvm_arch_update_irqfd_routing()<br /> (because the irqfd isn&amp;#39;t in the list). And so if the irqfd is in bypass<br /> mode, IRQs will continue to be posted using the old routing information.<br /> <br /> As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type<br /> results in KVM incorrectly keeping the IRQ in bypass mode, which is<br /> especially problematic on AMD as KVM tracks IRQs that are being posted to<br /> a vCPU in a list whose lifetime is tied to the irqfd.<br /> <br /> Without the help of KASAN to detect use-after-free, the most common<br /> sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to<br /> the memory for irqfd structure being re-allocated and zeroed, resulting<br /> in irqfd-&gt;irq_bypass_data being NULL when read by<br /> avic_update_iommu_vcpu_affinity():<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test<br /> Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025<br /> RIP: 0010:amd_iommu_update_ga+0x19/0xe0<br /> Call Trace:<br /> <br /> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]<br /> __avic_vcpu_load+0xf4/0x130 [kvm_amd]<br /> kvm_arch_vcpu_load+0x89/0x210 [kvm]<br /> vcpu_load+0x30/0x40 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]<br /> kvm_vcpu_ioctl+0x571/0x6a0 [kvm]<br /> __se_sys_ioctl+0x6d/0xb0<br /> do_syscall_64+0x6f/0x9d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x46893b<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> If AVIC is inhibited when the irfd is deassigned, the bug will manifest as<br /> list corruption, e.g. on the next irqfd assignment.<br /> <br /> list_add corruption. next-&gt;prev should be prev (ffff8d474d5cd588),<br /> but was 0000000000000000. (next=ffff8d8658f86530).<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:31!<br /> Oops: invalid opcode: 0000 [#1] SMP<br /> CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test<br /> Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025<br /> RIP: 0010:__list_add_valid_or_report+0x97/0xc0<br /> Call Trace:<br /> <br /> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]<br /> kvm_pi_update_irte+0xbf/0x190 [kvm]<br /> kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]<br /> irq_bypass_register_consumer+0xcd/0x170 [irqbypa<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix oops due to invalid pointer for kfree() in parse_longname()<br /> <br /> This fixes a kernel oops when reading ceph snapshot directories (.snap),<br /> for example by simply running `ls /mnt/my_ceph/.snap`.<br /> <br /> The variable str is guarded by __free(kfree), but advanced by one for<br /> skipping the initial &amp;#39;_&amp;#39; in snapshot names. Thus, kfree() is called<br /> with an invalid pointer. This patch removes the need for advancing the<br /> pointer so kfree() is called with correct memory pointer.<br /> <br /> Steps to reproduce:<br /> <br /> 1. Create snapshots on a cephfs volume (I&amp;#39;ve 63 snaps in my testcase)<br /> <br /> 2. Add cephfs mount to fstab<br /> $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" &gt;&gt; /etc/fstab<br /> <br /> 3. Reboot the system<br /> $ systemctl reboot<br /> <br /> 4. Check if it&amp;#39;s really mounted<br /> $ mount | grep stuff<br /> <br /> 5. List snapshots (expected 63 snapshots on my system)<br /> $ ls /mnt/test/stuff/.snap<br /> <br /> Now ls hangs forever and the kernel log shows the oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF<br /> <br /> syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6<br /> route. [0]<br /> <br /> Commit f72514b3c569 ("ipv6: clear RA flags when adding a static<br /> route") introduced logic to clear RTF_ADDRCONF from existing routes<br /> when a static route with the same nexthop is added. However, this<br /> causes a problem when the existing route has a gateway.<br /> <br /> When RTF_ADDRCONF is cleared from a route that has a gateway, that<br /> route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns<br /> true. The issue is that this route was never added to the<br /> fib6_siblings list.<br /> <br /> This leads to a mismatch between the following counts:<br /> <br /> - The sibling count computed by iterating fib6_next chain, which<br /> includes the newly ECMP-eligible route<br /> <br /> - The actual siblings in fib6_siblings list, which does not include<br /> that route<br /> <br /> When a subsequent ECMP route is added, fib6_add_rt2node() hits<br /> BUG_ON(sibling-&gt;fib6_nsiblings != rt-&gt;fib6_nsiblings) because the<br /> counts don&amp;#39;t match.<br /> <br /> Fix this by only clearing RTF_ADDRCONF when the existing route does<br /> not have a gateway. Routes without a gateway cannot qualify for ECMP<br /> anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing<br /> RTF_ADDRCONF on them is safe and matches the original intent of the<br /> commit.<br /> <br /> [0]:<br /> kernel BUG at net/ipv6/ip6_fib.c:1217!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217<br /> [...]<br /> Call Trace:<br /> <br /> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946<br /> ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571<br /> inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577<br /> sock_do_ioctl+0xdc/0x300 net/socket.c:1245<br /> sock_ioctl+0x576/0x790 net/socket.c:1366<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f