Vulnerabilities

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 /> 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 /> ice: Fix PTP NULL pointer dereference during VSI rebuild<br /> <br /> Fix race condition where PTP periodic work runs while VSI is being<br /> rebuilt, accessing NULL vsi-&gt;rx_rings.<br /> <br /> The sequence was:<br /> 1. ice_ptp_prepare_for_reset() cancels PTP work<br /> 2. ice_ptp_rebuild() immediately queues PTP work<br /> 3. VSI rebuild happens AFTER ice_ptp_rebuild()<br /> 4. PTP work runs and accesses NULL vsi-&gt;rx_rings<br /> <br /> Fix: Keep PTP work cancelled during rebuild, only queue it after<br /> VSI rebuild completes in ice_rebuild().<br /> <br /> Added ice_ptp_queue_work() helper function to encapsulate the logic<br /> for queuing PTP work, ensuring it&amp;#39;s only queued when PTP is supported<br /> and the state is ICE_PTP_READY.<br /> <br /> Error log:<br /> [ 121.392544] ice 0000:60:00.1: PTP reset successful<br /> [ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 121.392712] #PF: supervisor read access in kernel mode<br /> [ 121.392720] #PF: error_code(0x0000) - not-present page<br /> [ 121.392727] PGD 0<br /> [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)<br /> [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]<br /> [ 121.393042] Call Trace:<br /> [ 121.393047] <br /> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]<br /> [ 121.393202] kthread_worker_fn+0xa2/0x260<br /> [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]<br /> [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [ 121.393371] kthread+0x10d/0x230<br /> [ 121.393382] ? __pfx_kthread+0x10/0x10<br /> [ 121.393393] ret_from_fork+0x273/0x2b0<br /> [ 121.393407] ? __pfx_kthread+0x10/0x10<br /> [ 121.393417] ret_from_fork_asm+0x1a/0x30<br /> [ 121.393432]

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 /> rust_binder: correctly handle FDA objects of length zero<br /> <br /> Fix a bug where an empty FDA (fd array) object with 0 fds would cause an<br /> out-of-bounds error. The previous implementation used `skip == 0` to<br /> mean "this is a pointer fixup", but 0 is also the correct skip length<br /> for an empty FDA. If the FDA is at the end of the buffer, then this<br /> results in an attempt to write 8-bytes out of bounds. This is caught and<br /> results in an EINVAL error being returned to userspace.<br /> <br /> The pattern of using `skip == 0` as a special value originates from the<br /> C-implementation of Binder. As part of fixing this bug, this pattern is<br /> replaced with a Rust enum.<br /> <br /> I considered the alternate option of not pushing a fixup when the length<br /> is zero, but I think it&amp;#39;s cleaner to just get rid of the zero-is-special<br /> stuff.<br /> <br /> The root cause of this bug was diagnosed by Gemini CLI on first try. I<br /> used the following prompt:<br /> <br /> &gt; There appears to be a bug in @drivers/android/binder/thread.rs where<br /> &gt; the Fixups oob bug is triggered with 316 304 316 324. This implies<br /> &gt; that we somehow ended up with a fixup where buffer A has a pointer to<br /> &gt; buffer B, but the pointer is located at an index in buffer A that is<br /> &gt; out of bounds. Please investigate the code to find the bug. You may<br /> &gt; compare with @drivers/android/binder.c that implements this correctly.

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 /> HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer<br /> <br /> Add DMA buffer readiness check before reading DMA buffer to avoid<br /> unexpected NULL pointer accessing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: preserve error state in block data length handler<br /> <br /> When a block read returns an invalid length, zero or &gt;I2C_SMBUS_BLOCK_MAX,<br /> the length handler sets the state to IMX_I2C_STATE_FAILED. However,<br /> i2c_imx_master_isr() unconditionally overwrites this with<br /> IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns<br /> buffers and crashes the system.<br /> <br /> Guard the state transition to preserve error states set by the length<br /> handler.

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 /> procfs: avoid fetching build ID while holding VMA lock<br /> <br /> Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock<br /> or per-VMA lock, whichever was used to lock VMA under question, to avoid<br /> deadlock reported by syzbot:<br /> <br /> -&gt; #1 (&amp;mm-&gt;mmap_lock){++++}-{4:4}:<br /> __might_fault+0xed/0x170<br /> _copy_to_iter+0x118/0x1720<br /> copy_page_to_iter+0x12d/0x1e0<br /> filemap_read+0x720/0x10a0<br /> blkdev_read_iter+0x2b5/0x4e0<br /> vfs_read+0x7f4/0xae0<br /> ksys_read+0x12a/0x250<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #0 (&amp;sb-&gt;s_type-&gt;i_mutex_key#8){++++}-{4:4}:<br /> __lock_acquire+0x1509/0x26d0<br /> lock_acquire+0x185/0x340<br /> down_read+0x98/0x490<br /> blkdev_read_iter+0x2a7/0x4e0<br /> __kernel_read+0x39a/0xa90<br /> freader_fetch+0x1d5/0xa80<br /> __build_id_parse.isra.0+0xea/0x6a0<br /> do_procmap_query+0xd75/0x1050<br /> procfs_procmap_ioctl+0x7a/0xb0<br /> __x64_sys_ioctl+0x18e/0x210<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> rlock(&amp;mm-&gt;mmap_lock);<br /> lock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> lock(&amp;mm-&gt;mmap_lock);<br /> rlock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> <br /> *** DEADLOCK ***<br /> <br /> This seems to be exacerbated (as we haven&amp;#39;t seen these syzbot reports<br /> before that) by the recent:<br /> <br /> 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")<br /> <br /> To make this safe, we need to grab file refcount while VMA is still locked, but<br /> other than that everything is pretty straightforward. Internal build_id_parse()<br /> API assumes VMA is passed, but it only needs the underlying file reference, so<br /> just add another variant build_id_parse_file() that expects file passed<br /> directly.<br /> <br /> [akpm@linux-foundation.org: fix up kerneldoc]

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