{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-6.17.0-19", "linux-headers-6.17.0-19-generic", "linux-image-6.17.0-19-generic", "linux-modules-6.17.0-19-generic", "linux-tools-6.17.0-19", "linux-tools-6.17.0-19-generic" ], "removed": [ "linux-headers-6.17.0-14", "linux-headers-6.17.0-14-generic", "linux-image-6.17.0-14-generic", "linux-modules-6.17.0-14-generic", "linux-tools-6.17.0-14", "linux-tools-6.17.0-14-generic" ], "diff": [ "bpftool", "bsdextrautils", "bsdutils", "curl", "eject", "fdisk", "gnu-coreutils", "libblkid1:ppc64el", "libcurl3t64-gnutls:ppc64el", "libcurl4t64:ppc64el", "libfdisk1:ppc64el", "libfreetype6:ppc64el", "liblastlog2-2:ppc64el", "libmount1:ppc64el", "libnss3:ppc64el", "libpython3.13:ppc64el", "libpython3.13-minimal:ppc64el", "libpython3.13-stdlib:ppc64el", "libsmartcols1:ppc64el", "libuuid1:ppc64el", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:ppc64el", "linux-perf", "linux-tools-common", "linux-virtual", "login", "mount", "openssh-client", "openssh-server", "openssh-sftp-server", "python3-cryptography", "python3.13", "python3.13-gdbm", "python3.13-minimal", "snapd", "sos", "sudo", "util-linux", "uuid-runtime", "vim", "vim-common", "vim-runtime", "vim-tiny", "xxd" ] } }, "diff": { "deb": [ { "name": "bpftool", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "7.7.0+6.17.0-14.14" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "7.7.0+6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "bsdextrautils", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "bsdutils", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "1:2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "1:2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.1", "version": "8.14.1-2ubuntu1.1" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.2", "version": "8.14.1-2ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.am, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c, tests/http/test_13_proxy_auth.py,", " tests/http/testenv/curl.py.", " - CVE-2026-3784", " * SECURITY UPDATE: use after free in SMB connection reuse", " - debian/patches/CVE-2026-3805.patch: free the path in the request", " struct properly in lib/smb.c.", " - CVE-2026-3805", "" ], "package": "curl", "version": "8.14.1-2ubuntu1.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 09 Mar 2026 09:15:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "eject", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "fdisk", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "gnu-coreutils", "from_version": { "source_package_name": "coreutils", "source_package_version": "9.5-1ubuntu4", "version": "9.5-1ubuntu4" }, "to_version": { "source_package_name": "coreutils", "source_package_version": "9.5-1ubuntu4.1", "version": "9.5-1ubuntu4.1" }, "cves": [], "launchpad_bugs_fixed": [ 2137373 ], "changes": [ { "cves": [], "log": [ "", " * Fix slow performance of 'du' on large directories (>= 10K files)", " on Lustre filesystems by skipping inode sorting. The default", " behaviour of sorting dirents by inode numbers negatively impacts", " performance on Lustre because it interferes with Lustre's ability", " to prefetch file metadata via statahead. (LP: #2137373)", " - d/p/lp2137373-skip-dirent-inode-sorting-for-lustre.patch", "" ], "package": "coreutils", "version": "9.5-1ubuntu4.1", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2137373 ], "author": "Munir Siddiqui ", "date": "Fri, 23 Jan 2026 18:34:28 +0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libblkid1:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl3t64-gnutls:ppc64el", "from_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.1", "version": "8.14.1-2ubuntu1.1" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.2", "version": "8.14.1-2ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.am, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c, tests/http/test_13_proxy_auth.py,", " tests/http/testenv/curl.py.", " - CVE-2026-3784", " * SECURITY UPDATE: use after free in SMB connection reuse", " - debian/patches/CVE-2026-3805.patch: free the path in the request", " struct properly in lib/smb.c.", " - CVE-2026-3805", "" ], "package": "curl", "version": "8.14.1-2ubuntu1.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 09 Mar 2026 09:15:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64:ppc64el", "from_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.1", "version": "8.14.1-2ubuntu1.1" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.14.1-2ubuntu1.2", "version": "8.14.1-2ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3805", "url": "https://ubuntu.com/security/CVE-2026-3805", "cve_description": "When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.am, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c, tests/http/test_13_proxy_auth.py,", " tests/http/testenv/curl.py.", " - CVE-2026-3784", " * SECURITY UPDATE: use after free in SMB connection reuse", " - debian/patches/CVE-2026-3805.patch: free the path in the request", " struct properly in lib/smb.c.", " - CVE-2026-3805", "" ], "package": "curl", "version": "8.14.1-2ubuntu1.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 09 Mar 2026 09:15:00 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libfdisk1:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libfreetype6:ppc64el", "from_version": { "source_package_name": "freetype", "source_package_version": "2.13.3+dfsg-1build1", "version": "2.13.3+dfsg-1build1" }, "to_version": { "source_package_name": "freetype", "source_package_version": "2.13.3+dfsg-1ubuntu0.1", "version": "2.13.3+dfsg-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-23865", "url": "https://ubuntu.com/security/CVE-2026-23865", "cve_description": "An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.", "cve_priority": "medium", "cve_public_date": "2026-03-02 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-23865", "url": "https://ubuntu.com/security/CVE-2026-23865", "cve_description": "An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.", "cve_priority": "medium", "cve_public_date": "2026-03-02 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Integer Overflow", " - debian/patches/CVE-2026-23865.patch: Check for overflow in array", " size computation", " - CVE-2026-23865", "" ], "package": "freetype", "version": "2.13.3+dfsg-1ubuntu0.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 17:41:17 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "liblastlog2-2:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libmount1:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnss3:ppc64el", "from_version": { "source_package_name": "nss", "source_package_version": "2:3.114-1", "version": "2:3.114-1" }, "to_version": { "source_package_name": "nss", "source_package_version": "2:3.114-1ubuntu0.1", "version": "2:3.114-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-2781", "url": "https://ubuntu.com/security/CVE-2026-2781", "cve_description": "Integer overflow in the Libraries component in NSS. This vulnerability affects Firefox < 148, Firefox ESR < 140.8, Thunderbird < 148, and Thunderbird < 140.8.", "cve_priority": "medium", "cve_public_date": "2026-02-24 14:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-2781", "url": "https://ubuntu.com/security/CVE-2026-2781", "cve_description": "Integer overflow in the Libraries component in NSS. This vulnerability affects Firefox < 148, Firefox ESR < 140.8, Thunderbird < 148, and Thunderbird < 140.8.", "cve_priority": "medium", "cve_public_date": "2026-02-24 14:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow in platform-independent ghash", " - debian/patches/CVE-2026-2781.patch: properly cast len in", " nss/lib/freebl/gcm.c.", " - CVE-2026-2781", "" ], "package": "nss", "version": "2:3.114-1ubuntu0.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 26 Feb 2026 13:27:13 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.13:ppc64el", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.13-minimal:ppc64el", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.13-stdlib:ppc64el", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsmartcols1:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libuuid1:ppc64el", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19", "" ], "package": "linux-meta", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:59 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:04:30 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19", "" ], "package": "linux-meta", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:59 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:04:30 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19", "" ], "package": "linux-meta", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:59 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:04:30 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-libc-dev:ppc64el", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-perf", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19", "" ], "package": "linux-meta", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:59 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:04:30 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "login", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "1:4.16.0-2+really2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "1:4.16.0-2+really2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "mount", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5", "version": "1:10.0p1-5ubuntu5" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5.1", "version": "1:10.0p1-5ubuntu5.1" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: Improve rules for %-expansion of", " username in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:10.0p1-5ubuntu5.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5", "version": "1:10.0p1-5ubuntu5" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5.1", "version": "1:10.0p1-5ubuntu5.1" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: Improve rules for %-expansion of", " username in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:10.0p1-5ubuntu5.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5", "version": "1:10.0p1-5ubuntu5" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:10.0p1-5ubuntu5.1", "version": "1:10.0p1-5ubuntu5.1" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: Improve rules for %-expansion of", " username in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:10.0p1-5ubuntu5.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-cryptography", "from_version": { "source_package_name": "python-cryptography", "source_package_version": "43.0.0-1ubuntu1", "version": "43.0.0-1ubuntu1" }, "to_version": { "source_package_name": "python-cryptography", "source_package_version": "43.0.0-1ubuntu1.2", "version": "43.0.0-1ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" }, { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "launchpad_bugs_fixed": [ 2144373 ], "changes": [ { "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: ecc support regression (LP: #2144373)", " - debian/patches/CVE-2026-26007.patch: updated to remove problematic", " deprecation warning code which is causing a regression with ansible.", "" ], "package": "python-cryptography", "version": "43.0.0-1ubuntu1.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [ 2144373 ], "author": "Marc Deslauriers ", "date": "Sat, 14 Mar 2026 08:14:57 -0400" }, { "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Subgroup Attack Due to Missing Subgroup Validation for", " SECT Curves", " - debian/patches/CVE-2026-26007.patch: EC check key on cofactor > 1 in", " src/cryptography/hazmat/primitives/asymmetric/ec.py,", " src/cryptography/utils.py, src/rust/src/backend/ec.rs,", " tests/hazmat/primitives/test_ec.py.", " - CVE-2026-26007", "" ], "package": "python-cryptography", "version": "43.0.0-1ubuntu1.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 20 Feb 2026 08:22:42 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.13", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.13-gdbm", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.13-minimal", "from_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.3", "version": "3.13.7-1ubuntu0.3" }, "to_version": { "source_package_name": "python3.13", "source_package_version": "3.13.7-1ubuntu0.4", "version": "3.13.7-1ubuntu0.4" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.13", "version": "3.13.7-1ubuntu0.4", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:49:54 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.73+ubuntu25.10", "version": "2.73+ubuntu25.10" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.73+ubuntu25.10.1", "version": "2.73+ubuntu25.10.1" }, "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Local privilege escalation", " - debian/patches/CVE-2026-3888.patch: more precise prune pattern for", " tmpfiles.", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.73+ubuntu25.10.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Thu, 12 Mar 2026 12:25:05 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "sos", "from_version": { "source_package_name": "sos", "source_package_version": "4.10.0-1", "version": "4.10.0-1" }, "to_version": { "source_package_name": "sos", "source_package_version": "4.10.2-0ubuntu0.1", "version": "4.10.2-0ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 2136302 ], "changes": [ { "cves": [], "log": [ "", " * New 4.10.2 upstream release. (LP: #2136302)", "", " * For more details, full release note is available here:", " - https://github.com/sosreport/sos/releases/tag/4.10.2", "", " * d/control:", " - Add gpg to Recommends so that we are able to encrypt and", " decrypt sos reports", " - Update Replaces and Breaks with the new package version to ensure the", " upgrade path works", "", " * d/copyright: Aligned copyright with upstream Debian", "", " * Former patches, now fixed:", " - d/p/0001-Fix-Cleaner-Obfuscate-File.patch", "" ], "package": "sos", "version": "4.10.2-0ubuntu0.1", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2136302 ], "author": "Bryan Fraschetti ", "date": "Tue, 16 Dec 2025 12:32:13 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "sudo", "from_version": { "source_package_name": "sudo", "source_package_version": "1.9.17p2-1ubuntu1", "version": "1.9.17p2-1ubuntu1" }, "to_version": { "source_package_name": "sudo", "source_package_version": "1.9.17p2-1ubuntu1.1", "version": "1.9.17p2-1ubuntu1.1" }, "cves": [], "launchpad_bugs_fixed": [ 2143042 ], "changes": [ { "cves": [], "log": [ "", " * SECURITY UPDATE: exec_mailer gid issue (LP: #2143042)", " - debian/patches/lp2143042.patch: set group as well as uid when running", " the mailer and make a setuid(), setgid() or setgroups() failure fatal", " in include/sudo_eventlog.h, lib/eventlog/eventlog.c,", " lib/eventlog/eventlog_conf.c, plugins/sudoers/logging.c,", " plugins/sudoers/policy.c.", " - No CVE number", "" ], "package": "sudo", "version": "1.9.17p2-1ubuntu1.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [ 2143042 ], "author": "Marc Deslauriers ", "date": "Mon, 02 Mar 2026 07:52:23 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "util-linux", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "uuid-runtime", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.1", "version": "2.41-4ubuntu4.1" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.41-4ubuntu4.2", "version": "2.41-4ubuntu4.2" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.41-4ubuntu4.2", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 17:56:03 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6", "version": "2:9.1.0967-1ubuntu6" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6.1", "version": "2:9.1.0967-1ubuntu6.1" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0967-1ubuntu6.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:05:18 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-common", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6", "version": "2:9.1.0967-1ubuntu6" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6.1", "version": "2:9.1.0967-1ubuntu6.1" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0967-1ubuntu6.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:05:18 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-runtime", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6", "version": "2:9.1.0967-1ubuntu6" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6.1", "version": "2:9.1.0967-1ubuntu6.1" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0967-1ubuntu6.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:05:18 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-tiny", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6", "version": "2:9.1.0967-1ubuntu6" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6.1", "version": "2:9.1.0967-1ubuntu6.1" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0967-1ubuntu6.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:05:18 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6", "version": "2:9.1.0967-1ubuntu6" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0967-1ubuntu6.1", "version": "2:9.1.0967-1ubuntu6.1" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0967-1ubuntu6.1", "urgency": "medium", "distributions": "questing-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:05:18 +1100" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-6.17.0-19", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-headers-6.17.0-19 version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-headers-6.17.0-19 version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-headers-6.17.0-19-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-headers-6.17.0-19-generic version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-headers-6.17.0-19-generic version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-6.17.0-19-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-image-6.17.0-19-generic version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-image-6.17.0-19-generic version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-6.17.0-19-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-modules-6.17.0-19-generic version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-modules-6.17.0-19-generic version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-tools-6.17.0-19", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-tools-6.17.0-19 version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-tools-6.17.0-19 version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-tools-6.17.0-19-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.17.0-19.19", "version": "6.17.0-19.19" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.17.0-19.19", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2143480 ], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 15:30:11 +0300" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", "", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", "", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", "", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", "", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", "", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", "", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", "", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", "", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", "", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", "", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", "", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", "", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", "", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", "", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux", "version": "6.17.0-16.16", "urgency": "medium", "distributions": "questing", "launchpad_bugs_fixed": [ 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Edoardo Canepa ", "date": "Sat, 07 Feb 2026 11:03:42 +0100" } ], "notes": "linux-tools-6.17.0-19-generic version '6.17.0-19.19' (source package linux version '6.17.0-19.19') was added. linux-tools-6.17.0-19-generic version '6.17.0-19.19' has the same source package name, linux, as removed package linux-headers-6.17.0-14. As such we can use the source package version of the removed package, '6.17.0-14.14', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-6.17.0-14", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-6.17.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-6.17.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-6.17.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-6.17.0-14", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-6.17.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.17.0-14.14", "version": "6.17.0-14.14" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 25.10 questing image from release image serial 20260226 to 20260320", "from_series": "questing", "to_series": "questing", "from_serial": "20260226", "to_serial": "20260320", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }