{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1080-kvm", "linux-image-5.15.0-1080-kvm", "linux-kvm-headers-5.15.0-1080", "linux-modules-5.15.0-1080-kvm" ], "removed": [ "linux-headers-5.15.0-1079-kvm", "linux-image-5.15.0-1079-kvm", "linux-kvm-headers-5.15.0-1079", "linux-modules-5.15.0-1079-kvm" ], "diff": [ "linux-headers-kvm", "linux-image-kvm", "linux-kvm" ] } }, "diff": { "deb": [ { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1079.75", "version": "5.15.0.1079.75" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1080.76", "version": "5.15.0.1080.76" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1080", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1080.76", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 10:01:45 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1079.75", "version": "5.15.0.1079.75" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1080.76", "version": "5.15.0.1080.76" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1080", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1080.76", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 10:01:45 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1079.75", "version": "5.15.0.1079.75" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1080.76", "version": "5.15.0.1080.76" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1080", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1080.76", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 10:01:45 +0200" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1080-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1080.85", "version": "5.15.0-1080.85" }, "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "changes": [ { "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1080.85 -proposed tracker (LP: #2106968)", "", " [ Ubuntu: 5.15.0-140.150 ]", "", " * jammy/linux: 5.15.0-140.150 -proposed tracker (LP: #2106996)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.04.14)", " * NFS, overlay, fstab issue after update to kernel 5.15.0-133-generic and -134", " (LP: #2103598)", " - udf: Fix directory iteration for longer tail extents", " * Remove floppy kernel module causes null pointer deference (LP: #2104326)", " - floppy: fix add_disk() assumption on exit due to new developments", " * CVE-2025-21971", " - net_sched: Prevent creation of classes with TC_H_ROOT", " * CVE-2024-56599", " - wifi: ath10k: avoid NULL pointer error during sdio remove", " * CVE-2024-56721", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026)", " - afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY", " - afs: Fix directory format encoding struct", " - hung_task: move hung_task sysctl interface to hung_task.c", " - sysctl: use const for typically used max/min proc sysctls", " - sysctl: share unsigned long const values", " - fs: move inode sysctls to its own file", " - fs: move fs stat sysctls to file_table.c", " - fs: fix proc_handler for sysctl_nr_open", " - block: deprecate autoloading based on dev_t", " - block: retry call probe after request_module in blk_request_module", " - pstore/blk: trivial typo fixes", " - nvme: Add error check for xa_store in nvme_get_effects_log", " - partitions: ldm: remove the initial kernel-doc notation", " - select: Fix unbalanced user_access_end()", " - afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call", " - sched/psi: Use task->psi_flags to clear in CPU migration", " - sched/fair: Fix value reported by hot tasks pulled in /proc/schedstat", " - drm/etnaviv: Fix page property being used for non writecombine buffers", " - genirq: Make handle_enforce_irqctx() unconditionally available", " - wifi: rtlwifi: do not complete firmware loading needlessly", " - wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last step", " - wifi: rtlwifi: wait for firmware loading before releasing memory", " - wifi: rtlwifi: fix init_sw_vars leak when probe fails", " - wifi: rtlwifi: usb: fix workqueue leak when probe fails", " - spi: zynq-qspi: Add check for clk_enable()", " - dt-bindings: mmc: controller: clarify the address-cells description", " - spi: dt-bindings: add schema listing peripheral-specific properties", " - dt-bindings: Another pass removing cases of 'allOf' containing a '$ref'", " - dt-bindings: leds: Add Qualcomm Light Pulse Generator binding", " - dt-bindings: leds: Optional multi-led unit address", " - dt-bindings: leds: Add multicolor PWM LED bindings", " - dt-bindings: leds: class-multicolor: reference class directly in multi-led", " node", " - dt-bindings: leds: class-multicolor: Fix path to color definitions", " - rtlwifi: replace usage of found with dedicated list iterator variable", " - wifi: rtlwifi: remove unused timer and related code", " - wifi: rtlwifi: remove unused dualmac control leftovers", " - wifi: rtlwifi: destroy workqueue at rtl_deinit_core", " - wifi: rtlwifi: pci: wait for firmware loading before releasing memory", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - Revert \"HID: multitouch: Add support for lenovo Y9000P Touchpad\"", " - HID: multitouch: fix support for Goodix PID 0x01e9", " - regulator: dt-bindings: mt6315: Drop regulator-compatible property", " - ACPI: fan: cleanup resources in the error path of .probe()", " - cpupower: fix TSC MHz calculation", " - dt-bindings: mfd: bd71815: Fix rsense and typos", " - leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata()", " - cpufreq: schedutil: Fix superfluous updates caused by need_freq_update", " - clk: imx8mp: Fix clkout1/2 support", " - regulator: of: Implement the unwind path of of_regulator_match()", " - samples/landlock: Fix possible NULL dereference in parse_path()", " - wifi: wlcore: fix unbalanced pm_runtime calls", " - net/smc: fix data error when recvmsg with MSG_PEEK flag", " - landlock: Move filesystem helpers and add a new one", " - wifi: mt76: mt76u_vendor_request: Do not print error messages when -EPROTO", " - cpufreq: ACPI: Fix max-frequency computation", " - selftests: harness: fix printing of mismatch values in __EXPECT()", " - wifi: cfg80211: Handle specific BSSID in 6GHz scanning", " - wifi: cfg80211: adjust allocation of colocated AP data", " - clk: analogbits: Fix incorrect calculation of vco rate delta", " - selftests/landlock: Fix error message", " - net/mlxfw: Drop hard coded max FW flash image size", " - netfilter: nft_flow_offload: update tcp state flags under lock", " - tcp_cubic: fix incorrect HyStart round start detection", " - tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind", " - libbpf: Fix segfault due to libelf functions not setting errno", " - ASoC: sun4i-spdif: Add clock multiplier settings", " - perf header: Fix one memory leakage in process_bpf_btf()", " - perf header: Fix one memory leakage in process_bpf_prog_info()", " - perf bpf: Fix two memory leakages when calling", " perf_env__insert_bpf_prog_info()", " - ASoC: renesas: rz-ssi: Use only the proper amount of dividers", " - ktest.pl: Remove unused declarations in run_bisect_test function", " - crypto: hisilicon/sec - add some comments for soft fallback", " - crypto: hisilicon/sec - delete redundant blank lines", " - crypto: hisilicon/sec2 - optimize the error return process", " - crypto: hisilicon/sec2 - fix for aead icv error", " - crypto: hisilicon/sec2 - fix for aead invalid authsize", " - crypto: ixp4xx - fix OF node reference leaks in init_ixp_crypto()", " - padata: fix sysfs store callback check", " - perf top: Don't complain about lack of vmlinux when not resolving some", " kernel samples", " - perf report: Fix misleading help message about --demangle", " - padata: add pd get/put refcnt helper", " - ARM: at91: pm: change BU Power Switch to automatic mode", " - arm64: dts: mt8183: set DMIC one-wire mode on Damu", " - arm64: dts: mediatek: mt8516: fix GICv2 range", " - arm64: dts: mediatek: mt8516: fix wdt irq type", " - arm64: dts: mediatek: mt8516: remove 2 invalid i2c clocks", " - arm64: dts: mediatek: mt8516: add i2c clock-div property", " - arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A", " - RDMA/mlx4: Avoid false error about access to uninitialized gids array", " - arm64: dts: mediatek: mt8173-evb: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8173-evb: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8183: kenzo: Support second source touchscreen", " - arm64: dts: mediatek: mt8183: willow: Support second source touchscreen", " - memory: Add LPDDR2-info helpers", " - memory: tegra20-emc: Support matching timings by LPDDR2 configuration", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Drop pp3300_panel voltage", " settings", " - arm64: dts: qcom: msm8996: Fix up USB3 interrupts", " - arm64: dts: qcom: msm8994: Describe USB interrupts", " - arm64: dts: qcom: msm8916: correct sleep clock frequency", " - arm64: dts: qcom: msm8994: correct sleep clock frequency", " - arm64: dts: qcom: sc7280: correct sleep clock frequency", " - arm64: dts: qcom: sm6125: correct sleep clock frequency", " - arm64: dts: qcom: sm8250: correct sleep clock frequency", " - arm64: dts: qcom: sm8350: correct sleep clock frequency", " - arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280", " properties", " - arm64: dts: qcom: sdm845: Fix interrupt types of camss interrupts", " - ARM: dts: mediatek: mt7623: fix IR nodename", " - fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device()", " - RDMA/mlx5: Remove iova from struct mlx5_core_mkey", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - RDMA/mlx5: Fix indirect mkey ODP page count", " - xen/x86: free_p2m_page: use memblock_free_ptr() to free a virtual pointer", " - memblock: drop memblock_free_early_nid() and memblock_free_early()", " - of: reserved-memory: Do not make kmemleak ignore freed address", " - efi: sysfb_efi: fix W=1 warnings when EFI is not set", " - media: rc: iguanair: handle timeouts", " - media: lmedm04: Handle errors for lme2510_int_read", " - PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()", " - media: marvell: Add check for clk_enable()", " - media: i2c: imx412: Add missing newline to prints", " - media: i2c: ov9282: Correct the exposure offset", " - media: mipi-csis: Add check for clk_enable()", " - media: camif-core: Add check for clk_enable()", " - media: uvcvideo: Propagate buf->error to userspace", " - mtd: hyperbus: Make hyperbus_unregister_device() return void", " - mtd: hyperbus: hbmc-am654: Convert to platform remove callback returning", " void", " - mtd: hyperbus: hbmc-am654: fix an OF node reference leak", " - staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()", " - scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1", " - scsi: ufs: bsg: Delete bsg_dev when setting up bsg fails", " - ocfs2: mark dquot as inactive if failed to start trans while releasing dquot", " - module: Extend the preempt disabled section in", " dereference_symbol_descriptor().", " - NFSv4.2: fix COPY_NOTIFY xdr buf size calculation", " - NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE", " - tools/bootconfig: Fix the wrong format specifier", " - xfrm: replay: Fix the update of replay_esn->oseq_hi for GSO", " - dmaengine: ti: edma: fix OF node reference leaks in edma_driver", " - gpio: mxc: remove dead code after switch to DT-only", " - net: fec: implement TSO descriptor cleanup", " - PM: hibernate: Add error handling for syscore_suspend()", " - net: netdevsim: try to close UDP port harness races", " - ptp: Properly handle compat ioctls", " - perf trace: Fix runtime error of index out of bounds", " - vsock: Allow retrying on connect() failure", " - bgmac: reduce max frame size to support just MTU 1500", " - net: sh_eth: Fix missing rtnl lock in suspend/resume path", " - net: hsr: fix fill_frame_info() regression vs VLAN packets", " - genksyms: fix memory leak when the same symbol is added from source", " - genksyms: fix memory leak when the same symbol is read from *.symref file", " - kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST", " - kconfig: add warn-unknown-symbols sanity check", " - kconfig: require a space after '#' for valid input", " - kconfig: remove unused code for S_DEF_AUTO in conf_read_simple()", " - kconfig: deduplicate code in conf_read_simple()", " - kconfig: WERROR unmet symbol dependency", " - kconfig: fix memory leak in sym_warn_unmet_dep()", " - hexagon: fix using plain integer as NULL pointer warning in cmpxchg", " - hexagon: Fix unbalanced spinlock in die()", " - f2fs: Introduce linear search for dentries", " - ktest.pl: Check kernelrelease return in get_version", " - ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro", " - drivers/card_reader/rtsx_usb: Restore interrupt based detection", " - usb: gadget: f_tcm: Fix Get/SetInterface return value", " - usb: dwc3: core: Defer the probe until USB power supply ready", " - usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to PD_T_SENDER_RESPONSE", " - usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS", " - btrfs: output the reason for open_ctree() failure", " - btrfs: fix data race when accessing the inode's disk_i_size at", " btrfs_drop_extents()", " - btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper error handling", " - sched: Don't try to catch up excess steal time.", " - lockdep: Fix upper limit for LOCKDEP_*_BITS configs", " - x86/amd_nb: Restrict init function to AMD-based systems", " - tun: fix group permission check", " - mmc: core: Respect quirk_max_rate for non-UHS SDIO card", " - mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id", " - HID: Wacom: Add PCI Wacom device support", " - net/mlx5: use do_aux_work for PHC overflow checks", " - wifi: iwlwifi: avoid memory leak", " - i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz", " - APEI: GHES: Have GHES honor the panic= setting", " - net: wwan: iosm: Fix hibernation by re-binding the driver around it", " - mmc: sdhci-msm: Correctly set the load for the regulator", " - tipc: re-order conditions in tipc_crypto_key_rcv()", " - selftests/net/ipsec: Fix Null pointer dereference in rtattr_pack()", " - Input: allocate keycode for phone linking", " - platform/x86: acer-wmi: Ignore AC events", " - x86/mm: Don't disable PCID when INVLPG has been fixed by microcode", " - usb: chipidea: ci_hdrc_imx: use dev_err_probe()", " - usb: chipidea/ci_hdrc_imx: Convert to platform remove callback returning", " void", " - usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in", " the error path of .probe()", " - net/ncsi: Add NC-SI 1.2 Get MC MAC Address command", " - net/ncsi: fix locking in Get MAC Address handling", " - xfs: report realtime block quota limits on realtime directories", " - xfs: don't over-report free space or inodes in statvfs", " - usb: xhci: Add timeout argument in address_device USB HCD callback", " - nvme: handle connectivity loss in nvme_set_queue_count", " - firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry", " - gpu: drm_dp_cec: fix broken CEC adapter properties check", " - tg3: Disable tg3 PCIe AER on system reboot", " - udp: gso: do not drop small packets when PMTU reduces", " - gpio: pca953x: Improve interrupt support", " - net: atlantic: fix warning during hot unplug", " - x86/xen: fix xen_hypercall_hvm() to not clobber %rbx", " - x86/xen: add FRAME_END to xen_hypercall_hvm()", " - tun: revert fix group permission check", " - cpufreq: s3c64xx: Fix compilation warning", " - leds: lp8860: Write full EEPROM, not only half of it", " - drm/modeset: Handle tiled displays in pan_display_atomic.", " - s390/futex: Fix FUTEX_OP_ANDN implementation", " - m68k: vga: Fix I/O defines", " - arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma", " - KVM: s390: vsie: fix some corner-cases when grabbing vsie pages", " - drm/amd/pm: Mark MM activity as unsupported", " - drm/komeda: Add check for komeda_get_layer_fourcc_list()", " - drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes", " - Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection", " - clk: sunxi-ng: a100: enable MMC clock reparenting", " - clk: qcom: clk-alpha-pll: fix alpha mode configuration", " - clk: qcom: gcc-mdm9607: Fix cmd_rcgr offset for blsp1_uart6 rcg", " - clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate", " - efi: libstub: Use '-std=gnu11' to fix build with GCC 15", " - perf bench: Fix undefined behavior in cmpworker()", " - of: Correct child specifier used as input of the 2nd nexus node", " - of: Fix of_find_node_opts_by_path() handling of alias+path+options", " - of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'", " - HID: hid-sensor-hub: don't use stale platform-data on remove", " - wifi: rtlwifi: rtl8821ae: Fix media status report", " - usb: gadget: f_tcm: Translate error to sense", " - usb: gadget: f_tcm: Decrement command ref count on cleanup", " - usb: gadget: f_tcm: ep_autoconfig with fullspeed endpoint", " - usb: gadget: f_tcm: Don't prepare BOT write request twice", " - serial: sh-sci: Drop __initdata macro for port_cfg", " - serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is", " in use", " - MIPS: Loongson64: remove ROM Size unit in boardinfo", " - powerpc/pseries/eeh: Fix get PE state translation", " - dm-crypt: don't update io->sector after kcryptd_crypt_write_io_submit()", " - dm-crypt: track tag_offset in convert_context", " - mips/math-emu: fix emulation of the prefx instruction", " - ALSA: hda/realtek: Enable headset mic on Positivo C6400", " - PCI: endpoint: Finish virtual EP removal in pci_epf_remove_vepf()", " - nvme-pci: Add TUXEDO InfinityFlex to Samsung sleep quirk", " - nvme-pci: Add TUXEDO IBP Gen9 to Samsung sleep quirk", " - scsi: qla2xxx: Move FCE Trace buffer allocation to user control", " - scsi: storvsc: Set correct data length for sending SCSI command without", " payload", " - kbuild: Move -Wenum-enum-conversion to W=2", " - x86/boot: Use '-std=gnu11' to fix build with GCC 15", " - arm64: dts: qcom: sm8350: Fix MPSS memory length", " - crypto: qce - fix priority to be less than ARMv8 CE", " - xfs: Add error handling for xfs_reflink_cancel_cow_range", " - media: ccs: Clean up parsed CCS static data on parse failure", " - iio: light: as73211: fix channel handling in only-color triggered buffer", " - soc: qcom: smem_state: fix missing of_node_put in error path", " - media: mc: fix endpoint iteration", " - media: ov5640: fix get_light_freq on auto", " - media: ccs: Fix CCS static data parsing for large block sizes", " - media: ccs: Fix cleanup order in ccs_probe()", " - media: uvcvideo: Fix event flags in uvc_ctrl_send_events", " - media: uvcvideo: Remove redundant NULL assignment", " - crypto: qce - fix goto jump in error path", " - crypto: qce - unregister previously registered algos in error path", " - nvmem: qcom-spmi-sdam: Set size in struct nvmem_config", " - nvmem: core: improve range check for nvmem_cell_write()", " - vfio/platform: check the bounds of read/write syscalls", " - pnfs/flexfiles: retry getting layout segment for reads", " - ocfs2: fix incorrect CPU endianness conversion causing mount failure", " - mtd: onenand: Fix uninitialized retlen in do_otp_read()", " - misc: fastrpc: Fix registered buffer page address", " - net/ncsi: wait for the last response to Deselect Package before configuring", " channel", " - net: phy: c45-tjaxx: add delay between MDIO write and read in soft_reset", " - MIPS: ftrace: Declare ftrace_get_parent_ra_addr() as static", " - net/ncsi: use dev_set_mac_address() for Get MC MAC Address handling", " - gpio: xilinx: remove excess kernel doc", " - memory: tegra20-emc: Correct memory device mask", " - ocfs2: check dir i_size in ocfs2_find_entry", " - mptcp: prevent excessive coalescing on receive", " - ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu()", " - drm/i915/selftests: avoid using uninitialized context", " - gpio: bcm-kona: Fix GPIO lock/unlock for banks above bank 0", " - gpio: bcm-kona: Make sure GPIO bits are unlocked when requesting IRQ", " - gpio: bcm-kona: Add missing newline to dev_err format string", " - xen: remove a confusing comment on auto-translated guest I/O", " - x86/xen: allow larger contiguous memory regions in PV guests", " - media: cxd2841er: fix 64-bit division on gcc-9", " - PCI/DPC: Quirk PIO log size for Intel Raptor Lake-P", " - vfio/pci: Enable iowrite64 and ioread64 for vfio pci", " - Grab mm lock before grabbing pt lock", " - x86/mm/tlb: Only trim the mm_cpumask once a second", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet 5V", " - batman-adv: Ignore neighbor throughput metrics in error case", " - perf/x86/intel: Ensure LBRs are disabled when a CPU is starting", " - usb: roles: set switch registered flag early on", " - usb: gadget: udc: renesas_usb3: Fix compiler warning", " - usb: dwc2: gadget: remove of_node reference upon udc_stop", " - USB: pci-quirks: Fix HCCPARAMS register error for LS7A EHCI", " - usb: core: fix pipe creation for get_bMaxPacketSize0", " - USB: quirks: add USB_QUIRK_NO_LPM quirk for Teclast dist", " - USB: Add USB_QUIRK_NO_LPM quirk for sony xperia xz1 smartphone", " - USB: cdc-acm: Fill in Renesas R-Car D3 USB Download mode quirk", " - usb: cdc-acm: Fix handling of oversized fragments", " - USB: serial: option: add MeiG Smart SLM828", " - USB: serial: option: add Telit Cinterion FN990B compositions", " - USB: serial: option: fix Telit Cinterion FN990A name", " - USB: serial: option: drop MeiG Smart defines", " - can: c_can: fix unbalanced runtime PM disable in error path", " - can: j1939: j1939_sk_send_loop(): fix unable to send messages with data", " length zero", " - alpha: make stack 16-byte aligned (most cases)", " - efi: Avoid cold plugged memory for placing the kernel", " - cgroup: fix race between fork and cgroup.kill", " - serial: 8250: Fix fifo underflow on flush", " - alpha: align stack for page fault and user unaligned trap handlers", " - gpio: stmpe: Check return value of stmpe_reg_read in", " stmpe_gpio_irq_sync_unlock", " - regmap-irq: Add missing kfree()", " - arm64: Handle .ARM.attributes section in linker scripts", " - mlxsw: Add return value check for mlxsw_sp_port_get_stats_raw()", " - btrfs: fix hole expansion when writing at an offset beyond EOF", " - clocksource: Replace cpumask_weight() with cpumask_empty()", " - clocksource: Use pr_info() for \"Checking clocksource synchronization\"", " message", " - ipv4: add RCU protection to ip4_dst_hoplimit()", " - net: treat possible_net_t net pointer as an RCU one and add read_pnet_rcu()", " - net: add dev_net_rcu() helper", " - ipv4: use RCU protection in rt_is_expired()", " - ipv4: use RCU protection in inet_select_addr()", " - Namespaceify min_pmtu sysctl", " - Namespaceify mtu_expires sysctl", " - selftest: net: Test IPv4 PMTU exceptions with DSCP and ECN", " - net: ipv4: Cache pmtu for all packet paths if multipath enabled", " - neighbour: delete redundant judgment statements", " - drm/tidss: Fix issue in irq handling causing irq-flood issue", " - drm/tidss: Clear the interrupt status for interrupts being disabled", " - kdb: Do not assume write() callback available", " - alpha: replace hardcoded stack offsets with autogenerated ones", " - nilfs2: do not output warnings when clearing dirty buffers", " - can: ems_pci: move ASIX AX99100 ids to pci_ids.h", " - serial: 8250_pci: add support for ASIX AX99100", " - parport_pc: add support for ASIX AX99100", " - netdevsim: print human readable IP address", " - selftests: rtnetlink: update netdevsim ipsec output format", " - ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus", " - x86/i8253: Disable PIT timer 0 when not in use", " - Revert \"btrfs: avoid monopolizing a core when activating a swap file\"", " - btrfs: avoid monopolizing a core when activating a swap file", " - arm64: mte: Do not allow PROT_MTE on MAP_HUGETLB user mappings", " - crypto: testmgr - fix wrong key length for pkcs1pad", " - crypto: testmgr - Fix wrong test case of RSA", " - crypto: testmgr - fix version number of RSA tests", " - crypto: testmgr - populate RSA CRT parameters in RSA test vectors", " - crypto: testmgr - some more fixes to RSA test vectors", " - mm: update mark_victim tracepoints fields", " - drm/probe-helper: Create a HPD IRQ event helper for a single connector", " - drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()", " - ASoC: renesas: rz-ssi: Add a check for negative sample_space", " - arm64: dts: mediatek: mt8183: Disable DSI display output by default", " - tpm: Use managed allocation for bios event log", " - kfence: allow use of a deferrable timer", " - [Config] updateconfigs to disable new KFENCE_DEFERRABLE", " - kfence: enable check kfence canary on panic via boot param", " - kfence: skip __GFP_THISNODE allocations on NUMA systems", " - soc: mediatek: mtk-devapc: Switch to devm_clk_get_enabled()", " - soc: mediatek: mtk-devapc: Fix leaking IO map on error paths", " - soc/mediatek: mtk-devapc: Convert to platform remove callback returning void", " - soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove", " - media: uvcvideo: Set error_idx during ctrl_commit errors", " - media: uvcvideo: Refactor iterators", " - media: uvcvideo: Only save async fh if success", " - batman-adv: Drop initialization of flexible ethtool_link_ksettings", " - usb: dwc3: Increase DWC3 controller halt timeout", " - usb: dwc3: Fix timeout issue during controller enter/exit from halt state", " - powerpc/64s/mm: Move __real_pte stubs into hash-4k.h", " - powerpc/64s: Rewrite __real_pte() and __rpte_to_hidx() as static inline", " - ALSA: hda/realtek: Fixup ALC225 depop procedure", " - geneve: Suppress list corruption splat in geneve_destroy_tunnels().", " - net: extract port range fields from fl_flow_key", " - flow_dissector: Fix handling of mixed port and port-range keys", " - flow_dissector: Fix port range key handling in BPF conversion", " - net: Add non-RCU dev_getbyhwaddr() helper", " - arp: switch to dev_getbyhwaddr() in arp_req_set_public()", " - power: supply: da9150-fg: fix potential overflow", " - nvme/ioctl: add missing space in err message", " - bpf: skip non exist keys in generic_map_lookup_batch", " - ALSA: hda/conexant: Add quirk for HP ProBook 450 G4 mute LED", " - acct: block access to kernel internal filesystems", " - mtd: rawnand: cadence: fix error code in cadence_nand_init()", " - mtd: rawnand: cadence: use dma_map_resource for sdma address", " - mtd: rawnand: cadence: fix incorrect device in dma_unmap_single", " - x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit", " - IB/mlx5: Set and get correct qp_num for a DCT QP", " - ovl: use wrappers to all vfs_*xattr() calls", " - ovl: pass ofs to creation operations", " - scsi: core: Don't memset() the entire scsi_cmnd in scsi_init_command()", " - scsi: core: Clear driver private data when retrying request", " - RDMA/mlx5: Fix bind QP error cleanup flow", " - sunrpc: suppress warnings for unused procfs functions", " - ALSA: usb-audio: Avoid dropping MIDI events at closing multiple ports", " - Bluetooth: L2CAP: Fix L2CAP_ECRED_CONN_RSP response", " - afs: remove variable nr_servers", " - afs: Make it possible to find the volumes that are using a server", " - afs: Fix the server_list to unuse a displaced server rather than putting it", " - net: loopback: Avoid sending IP packets without an Ethernet header", " - net: cadence: macb: Synchronize stats calculations", " - ASoC: es8328: fix route from DAC to output", " - ipvs: Always clear ipvs_property flag in skb_scrub_packet()", " - tcp: Defer ts_recent changes until req is owned", " - net: mvpp2: cls: Fixed Non IP flow, with vlan tag flow defination.", " - net/mlx5: IRQ, Fix null string in debug print", " - seg6: add support for SRv6 H.Encaps.Red behavior", " - seg6: add support for SRv6 H.L2Encaps.Red behavior", " - include: net: add static inline dst_dev_overhead() to dst.h", " - net: ipv6: seg6_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in seg6 lwt", " - net: ipv6: rpl_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in rpl lwt", " - x86/CPU: Fix warm boot hang regression on AMD SC1100 SoC systems", " - ftrace: Avoid potential division by zero in function_stat_show()", " - ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2", " - perf/core: Fix low freq setting via IOC_PERIOD", " - drm/amd/display: Fix HPD after gpu reset", " - net: enetc: fix the off-by-one issue in enetc_map_tx_buffs()", " - net: enetc: update UDP checksum when updating originTimestamp field", " - net: enetc: correct the xdp_tx statistics", " - phy: tegra: xusb: reset VBUS & ID OVERRIDE", " - phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk", " - vmlinux.lds: Ensure that const vars with relocations are mapped R/O", " - intel_idle: Handle older CPUs, which stop the TSC in deeper C states,", " correctly", " - drm/amdgpu: Check extended configuration space register when system uses", " large bar", " - drm/amdgpu: disable BAR resize on Dell G5 SE", " - Revert \"of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'\"", " - HID: appleir: Fix potential NULL dereference at raw event handle", " - gpio: rcar: Use raw_spinlock to protect register access", " - gpio: aggregator: protect driver attr handlers against module unload", " - ALSA: hda: intel: Add Dell ALC3271 to power_save denylist", " - ALSA: hda/realtek: update ALC222 depop optimize", " - drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress 200M", " - platform/x86: thinkpad_acpi: Add battery quirk for ThinkPad X131e", " - x86/cacheinfo: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Properly parse CPUID leaf 0x2 TLB descriptor 0x63", " - wifi: cfg80211: regulatory: improve invalid hints checking", " - wifi: nl80211: reject cooked mode if it is set along with other flags", " - rapidio: add check for rio_add_net() in rio_scan_alloc_net()", " - rapidio: fix an API misues when rio_add_net() fails", " - s390/traps: Fix test_monitor_call() inline assembly", " - block: fix conversion of GPT partition name to 7-bit", " - mm/page_alloc: fix uninitialized variable", " - mm: don't skip arch_sync_kernel_mappings() in error paths", " - wifi: iwlwifi: limit printed string from FW file", " - HID: google: fix unused variable warning under !CONFIG_ACPI", " - HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()", " - nvmet-tcp: Fix a possible sporadic response drops in weakly ordered arch", " - net: gso: fix ownership in __udp_gso_segment", " - caif_virtio: fix wrong pointer check in cfv_probe()", " - hwmon: (pmbus) Initialise page count in pmbus_identify()", " - hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor table", " - hwmon: (ad7314) Validate leading zero bits and return error", " - ALSA: usx2y: validate nrpacks module parameter on probe", " - llc: do not use skb_get() before dev_queue_xmit()", " - hwmon: fix a NULL vs IS_ERR_OR_NULL() check in xgene_hwmon_probe()", " - drm/sched: Fix preprocessor guard", " - be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink", " - net: hns3: make sure ptp clock is unregister and freed if", " hclge_ptp_get_cycle returns an error", " - ppp: Fix KMSAN uninit-value warning with bpf", " - vlan: enforce underlying device type", " - x86/sgx: Support loading enclave page without VMA permissions check", " - x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes()", " - x86/sgx: Export sgx_encl_{grow,shrink}()", " - x86/sgx: Support VA page allocation without reclaiming", " - x86/sgx: Fix size overflows in sgx_encl_create()", " - exfat: fix soft lockup in exfat_clear_bitmap", " - net-timestamp: support TCP GSO case for a few missing flags", " - sched/fair: Fix potential memory corruption in child_cfs_rq_on_list", " - net: ipv6: fix dst ref loop in ila lwtunnel", " - net: ipv6: fix missing dst ref drop in ila lwtunnel", " - gpio: rcar: Fix missing of_node_put() call", " - Revert \"drivers/card_reader/rtsx_usb: Restore interrupt based detection\"", " - usb: renesas_usbhs: Call clk_put()", " - usb: renesas_usbhs: Use devm_usb_get_phy()", " - usb: hub: lack of clearing xHC resources", " - usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass Storage Card Reader", " - usb: renesas_usbhs: Flush the notify_hotplug_work", " - usb: atm: cxacru: fix a flaw in existing endpoint checks", " - usb: dwc3: Set SUSPENDENABLE soon after phy init", " - usb: dwc3: gadget: Prevent irq storm when TH re-executes", " - usb: typec: ucsi: increase timeout for PPM reset operations", " - usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix functionality", " - usb: gadget: Set self-powered based on MaxPower and bmAttributes", " - usb: gadget: Fix setting self-powered state on suspend", " - usb: gadget: Check bmAttributes only if configuration is valid", " - xhci: pci: Fix indentation in the PCI device ID definitions", " - usb: xhci: Enable the TRB overfetch quirk on VIA VL805", " - mei: me: add panther lake P DID", " - intel_th: pci: Add Arrow Lake support", " - intel_th: pci: Add Panther Lake-H support", " - intel_th: pci: Add Panther Lake-P/U support", " - slimbus: messaging: Free transaction ID in delayed interrupt scenario", " - bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock", " - eeprom: digsy_mtc: Make GPIO lookup table match the device", " - drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl", " - media: uvcvideo: Avoid invalid memory access", " - media: uvcvideo: Avoid returning invalid controls", " - md: select BLOCK_LEGACY_AUTOLOAD", " - [Config] updateconfigs to select BLOCK_LEGACY_AUTOLOAD", " - mtd: rawnand: cadence: fix unchecked dereference", " - spi-mxs: Fix chipselect glitch", " - nilfs2: move page release outside of nilfs_delete_entry and nilfs_set_link", " - nilfs2: eliminate staggered calls to kunmap in nilfs_rename", " - bpf, vsock: Invoke proto::close on close()", " - kbuild: userprogs: use correct lld when linking through clang", " - net: ipv6: fix dst refleaks in rpl, seg6 and ioam6 lwtunnels", " - Linux 5.15.179", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21647", " - sched: sch_cake: add bounds checks to host bulk flow fairness counts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58002", " - media: uvcvideo: Remove dangling pointers", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58079", " - media: uvcvideo: Fix crash during unbind if gpio unit is in use", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21721", " - nilfs2: handle errors that nilfs_prepare_chunk() may return", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-26982", " - Squashfs: check the inode number is not the invalid value of zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21844", " - smb: client: Add check for next_buffer in receive_encrypted_standard()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58090", " - sched/core: Prevent rescheduling when interrupts are disabled", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21875", " - mptcp: always handle address removal under msk socket lock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21877", " - usbnet: gl620a: fix endpoint checking in genelink_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21878", " - i2c: npcm: disable interrupt enable bit before devm_request_irq", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21887", " - ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21846", " - acct: perform last write from workqueue", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21848", " - nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21862", " - drop_monitor: fix incorrect initialization order", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21871", " - tee: optee: Fix supplicant wait loop", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21865", " - gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21858", " - geneve: Fix use-after-free in geneve_find_dev().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21866", " - powerpc/code-patching: Fix KASAN hit by not flagging text patching area as", " VM_ALLOC", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21859", " - USB: gadget: f_midi: f_midi_complete to call queue_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21823", " - batman-adv: Drop unmanaged ELP metric worker", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58005", " - tpm: Change to kvalloc() in eventlog/acpi.c", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21748", " - ksmbd: fix integer overflows on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57977", " - memcg: fix soft lockup in the OOM process", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57978", " - media: imx-jpeg: Fix potential error pointer dereference in detach_pm()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57979", " - pps: Fix a use-after-free", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21811", " - nilfs2: protect access to buffers with no active references", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21722", " - nilfs2: do not force clear folio if buffer is referenced", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58086", " - drm/v3d: Stop active perfmon if it is being destroyed", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21758", " - ipv6: mcast: add RCU protection to mld_newpack()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21760", " - ndisc: extend RCU protection in ndisc_send_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21761", " - openvswitch: use RCU protection in ovs_vport_cmd_fill_info()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21762", " - arp: use RCU protection in arp_xmit()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21763", " - neighbour: use RCU protection in __neigh_notify()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21764", " - ndisc: use RCU protection in ndisc_alloc_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21765", " - ipv6: use RCU protection in ip6_default_advmss()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21766", " - ipv4: use RCU protection in __ip_rt_update_pmtu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21767", " - clocksource: Use migrate_disable() to avoid calling get_random_u32() in", " atomic context", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21772", " - partitions: mac: fix handling of bogus partition table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21704", " - usb: cdc-acm: Check control transfer buffer size before access", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21776", " - USB: hub: Ignore non-compliant devices with too many configs or interfaces", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21835", " - usb: gadget: f_midi: fix MIDI Streaming descriptor lengths", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21779", " - KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21781", " - batman-adv: fix panic during interface removal", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21782", " - orangefs: fix a oob in orangefs_debug_write", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57834", " - media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21785", " - arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21787", " - team: better TEAM_OPTION_TYPE_STRING validation", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21791", " - vrf: use RCU protection in l3mdev_l3_out()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58020", " - HID: multitouch: Add NULL check in mt_input_configured", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21795", " - NFSD: fix hang in nfsd4_shutdown_callback", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21796", " - nfsd: clear acl_access/acl_default after releasing them", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21820", " - tty: xilinx_uartps: split sysrq handling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21814", " - ptp: Ensure info->enable callback is always set", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21735", " - NFC: nci: Add bounds checking in nci_hci_create_pipe()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21736", " - nilfs2: fix possible int overflows in nilfs_fiemap()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58001", " - ocfs2: handle a symlink read error correctly", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58007", " - soc: qcom: socinfo: Avoid out of bounds read of serial number", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21744", " - wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21745", " - blk-cgroup: Fix class @block_class's subsystem refcount leakage", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58076", " - clk: qcom: gcc-sm6350: Add missing parent_map for two clocks", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58083", " - KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58010", " - binfmt_flat: Fix integer overflow bug on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21749", " - net: rose: lock the socket in rose_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57981", " - usb: xhci: Fix NULL pointer dereference on certain command aborts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21684", " - gpio: xilinx: Convert gpio_lock to raw spinlock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58085", " - tomoyo: don't emit warning in tomoyo_write_control()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58014", " - wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58016", " - safesetid: check size of policy writes", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58017", " - printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21753", " - btrfs: fix use-after-free when attempting to join an aborted transaction", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58055", " - usb: gadget: f_tcm: Don't free command immediately", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57980", " - media: uvcvideo: Fix double free in error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21707", " - mptcp: consolidate suboption status", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21708", " - net: usb: rtl8150: enable basic endpoint checking", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21826", " - netfilter: nf_tables: reject mismatching sum of field_len with set key", " length", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21715", " - net: davicom: fix UAF in dm9000_drv_remove", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21718", " - net: rose: fix timer races against user threads", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21719", " - ipmr: do not call mr_mfc_uses_dev() for unres entries", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21802", " - net: hns3: fix oops when unload drivers paralleling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58058", " - ubifs: skip dumping tnc tree when zroot is null", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58069", " - rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21804", " - PCI: rcar-ep: Fix incorrect variable used when calling", " devm_request_mem_region()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58034", " - memory: tegra20-emc: fix an OF node reference bug in", " tegra_emc_find_node_by_ram_code()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57973", " - rdma/cxgb4: Prevent potential integer overflow on 32bit", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21726", " - padata: avoid UAF for reorder_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21727", " - padata: fix UAF in padata_reorder", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21728", " - bpf: Send signals asynchronously if !preemptible", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21711", " - net/rose: prevent integer overflows in rose_setsockopt()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21799", " - net: ethernet: ti: am65-cpsw: fix freeing IRQ in", " am65_cpsw_nuss_remove_tx_chns()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21806", " - net: let net.core.dev_weight always be non-zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21830", " - landlock: Handle weird files", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58071", " - team: prevent adding a device which is already a team device lower", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58063", " - wifi: rtlwifi: fix memory leaks and invalid access at probe error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58072", " - wifi: rtlwifi: remove unused check_buddy_priv", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58051", " - ipmi: ipmb: Add check devm_kasprintf() returned value", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58052", " - drm/amdgpu: Fix potential NULL pointer dereference in", " atomctrl_get_smc_sclk_range_table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57986", " - HID: core: Fix assumption that Resolution Multipliers must be in Logical", " Collections", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21731", " - nbd: don't allow reconnect after disconnect", " * Fix bugs preventing boot on Intel TDX-enabled hosts (LP: #2097811)", " - x86/mtrr: Remove physical address size calculation", " * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport", " (LP: #2104380)", " - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n", " * nfsd hangs and never recovers after NFS4ERR_DELAY and a connection loss", " (LP: #2103564)", " - NFSD: Reset cb_seq_status after NFS4ERR_DELAY", " * kernel hard lockup in cgroups during eBPF workload (LP: #2089318)", " - cgroup: cgroup: Honor caller's cgroup NS when resolving cgroup id", " - cgroup: Homogenize cgroup_get_from_id() return value", " - cgroup: Make cgroup_get_from_id() prettier", " - cgroup.c: add helper __cset_cgroup_from_root to cleanup duplicated codes", " - cgroup: Reorganize css_set_lock and kernfs path processing", " * CVE-2023-52664", " - net: atlantic: eliminate double free in error handling logic", " * CVE-2023-52927", " - netfilter: allow exp not to be removed in nf_ct_find_expectation", "" ], "package": "linux-kvm", "version": "5.15.0-1080.85", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 09:33:48 +0200" } ], "notes": "linux-headers-5.15.0-1080-kvm version '5.15.0-1080.85' (source package linux-kvm version '5.15.0-1080.85') was added. linux-headers-5.15.0-1080-kvm version '5.15.0-1080.85' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1079-kvm. As such we can use the source package version of the removed package, '5.15.0-1079.84', 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-5.15.0-1080-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1079.84", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1080.85", "version": "5.15.0-1080.85" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1080.85", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1080.85", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 10:03:27 +0200" } ], "notes": "linux-image-5.15.0-1080-kvm version '5.15.0-1080.85' (source package linux-signed-kvm version '5.15.0-1080.85') was added. linux-image-5.15.0-1080-kvm version '5.15.0-1080.85' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1079-kvm. As such we can use the source package version of the removed package, '5.15.0-1079.84', 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-kvm-headers-5.15.0-1080", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1080.85", "version": "5.15.0-1080.85" }, "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "changes": [ { "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1080.85 -proposed tracker (LP: #2106968)", "", " [ Ubuntu: 5.15.0-140.150 ]", "", " * jammy/linux: 5.15.0-140.150 -proposed tracker (LP: #2106996)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.04.14)", " * NFS, overlay, fstab issue after update to kernel 5.15.0-133-generic and -134", " (LP: #2103598)", " - udf: Fix directory iteration for longer tail extents", " * Remove floppy kernel module causes null pointer deference (LP: #2104326)", " - floppy: fix add_disk() assumption on exit due to new developments", " * CVE-2025-21971", " - net_sched: Prevent creation of classes with TC_H_ROOT", " * CVE-2024-56599", " - wifi: ath10k: avoid NULL pointer error during sdio remove", " * CVE-2024-56721", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026)", " - afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY", " - afs: Fix directory format encoding struct", " - hung_task: move hung_task sysctl interface to hung_task.c", " - sysctl: use const for typically used max/min proc sysctls", " - sysctl: share unsigned long const values", " - fs: move inode sysctls to its own file", " - fs: move fs stat sysctls to file_table.c", " - fs: fix proc_handler for sysctl_nr_open", " - block: deprecate autoloading based on dev_t", " - block: retry call probe after request_module in blk_request_module", " - pstore/blk: trivial typo fixes", " - nvme: Add error check for xa_store in nvme_get_effects_log", " - partitions: ldm: remove the initial kernel-doc notation", " - select: Fix unbalanced user_access_end()", " - afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call", " - sched/psi: Use task->psi_flags to clear in CPU migration", " - sched/fair: Fix value reported by hot tasks pulled in /proc/schedstat", " - drm/etnaviv: Fix page property being used for non writecombine buffers", " - genirq: Make handle_enforce_irqctx() unconditionally available", " - wifi: rtlwifi: do not complete firmware loading needlessly", " - wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last step", " - wifi: rtlwifi: wait for firmware loading before releasing memory", " - wifi: rtlwifi: fix init_sw_vars leak when probe fails", " - wifi: rtlwifi: usb: fix workqueue leak when probe fails", " - spi: zynq-qspi: Add check for clk_enable()", " - dt-bindings: mmc: controller: clarify the address-cells description", " - spi: dt-bindings: add schema listing peripheral-specific properties", " - dt-bindings: Another pass removing cases of 'allOf' containing a '$ref'", " - dt-bindings: leds: Add Qualcomm Light Pulse Generator binding", " - dt-bindings: leds: Optional multi-led unit address", " - dt-bindings: leds: Add multicolor PWM LED bindings", " - dt-bindings: leds: class-multicolor: reference class directly in multi-led", " node", " - dt-bindings: leds: class-multicolor: Fix path to color definitions", " - rtlwifi: replace usage of found with dedicated list iterator variable", " - wifi: rtlwifi: remove unused timer and related code", " - wifi: rtlwifi: remove unused dualmac control leftovers", " - wifi: rtlwifi: destroy workqueue at rtl_deinit_core", " - wifi: rtlwifi: pci: wait for firmware loading before releasing memory", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - Revert \"HID: multitouch: Add support for lenovo Y9000P Touchpad\"", " - HID: multitouch: fix support for Goodix PID 0x01e9", " - regulator: dt-bindings: mt6315: Drop regulator-compatible property", " - ACPI: fan: cleanup resources in the error path of .probe()", " - cpupower: fix TSC MHz calculation", " - dt-bindings: mfd: bd71815: Fix rsense and typos", " - leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata()", " - cpufreq: schedutil: Fix superfluous updates caused by need_freq_update", " - clk: imx8mp: Fix clkout1/2 support", " - regulator: of: Implement the unwind path of of_regulator_match()", " - samples/landlock: Fix possible NULL dereference in parse_path()", " - wifi: wlcore: fix unbalanced pm_runtime calls", " - net/smc: fix data error when recvmsg with MSG_PEEK flag", " - landlock: Move filesystem helpers and add a new one", " - wifi: mt76: mt76u_vendor_request: Do not print error messages when -EPROTO", " - cpufreq: ACPI: Fix max-frequency computation", " - selftests: harness: fix printing of mismatch values in __EXPECT()", " - wifi: cfg80211: Handle specific BSSID in 6GHz scanning", " - wifi: cfg80211: adjust allocation of colocated AP data", " - clk: analogbits: Fix incorrect calculation of vco rate delta", " - selftests/landlock: Fix error message", " - net/mlxfw: Drop hard coded max FW flash image size", " - netfilter: nft_flow_offload: update tcp state flags under lock", " - tcp_cubic: fix incorrect HyStart round start detection", " - tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind", " - libbpf: Fix segfault due to libelf functions not setting errno", " - ASoC: sun4i-spdif: Add clock multiplier settings", " - perf header: Fix one memory leakage in process_bpf_btf()", " - perf header: Fix one memory leakage in process_bpf_prog_info()", " - perf bpf: Fix two memory leakages when calling", " perf_env__insert_bpf_prog_info()", " - ASoC: renesas: rz-ssi: Use only the proper amount of dividers", " - ktest.pl: Remove unused declarations in run_bisect_test function", " - crypto: hisilicon/sec - add some comments for soft fallback", " - crypto: hisilicon/sec - delete redundant blank lines", " - crypto: hisilicon/sec2 - optimize the error return process", " - crypto: hisilicon/sec2 - fix for aead icv error", " - crypto: hisilicon/sec2 - fix for aead invalid authsize", " - crypto: ixp4xx - fix OF node reference leaks in init_ixp_crypto()", " - padata: fix sysfs store callback check", " - perf top: Don't complain about lack of vmlinux when not resolving some", " kernel samples", " - perf report: Fix misleading help message about --demangle", " - padata: add pd get/put refcnt helper", " - ARM: at91: pm: change BU Power Switch to automatic mode", " - arm64: dts: mt8183: set DMIC one-wire mode on Damu", " - arm64: dts: mediatek: mt8516: fix GICv2 range", " - arm64: dts: mediatek: mt8516: fix wdt irq type", " - arm64: dts: mediatek: mt8516: remove 2 invalid i2c clocks", " - arm64: dts: mediatek: mt8516: add i2c clock-div property", " - arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A", " - RDMA/mlx4: Avoid false error about access to uninitialized gids array", " - arm64: dts: mediatek: mt8173-evb: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8173-evb: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8183: kenzo: Support second source touchscreen", " - arm64: dts: mediatek: mt8183: willow: Support second source touchscreen", " - memory: Add LPDDR2-info helpers", " - memory: tegra20-emc: Support matching timings by LPDDR2 configuration", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Drop pp3300_panel voltage", " settings", " - arm64: dts: qcom: msm8996: Fix up USB3 interrupts", " - arm64: dts: qcom: msm8994: Describe USB interrupts", " - arm64: dts: qcom: msm8916: correct sleep clock frequency", " - arm64: dts: qcom: msm8994: correct sleep clock frequency", " - arm64: dts: qcom: sc7280: correct sleep clock frequency", " - arm64: dts: qcom: sm6125: correct sleep clock frequency", " - arm64: dts: qcom: sm8250: correct sleep clock frequency", " - arm64: dts: qcom: sm8350: correct sleep clock frequency", " - arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280", " properties", " - arm64: dts: qcom: sdm845: Fix interrupt types of camss interrupts", " - ARM: dts: mediatek: mt7623: fix IR nodename", " - fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device()", " - RDMA/mlx5: Remove iova from struct mlx5_core_mkey", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - RDMA/mlx5: Fix indirect mkey ODP page count", " - xen/x86: free_p2m_page: use memblock_free_ptr() to free a virtual pointer", " - memblock: drop memblock_free_early_nid() and memblock_free_early()", " - of: reserved-memory: Do not make kmemleak ignore freed address", " - efi: sysfb_efi: fix W=1 warnings when EFI is not set", " - media: rc: iguanair: handle timeouts", " - media: lmedm04: Handle errors for lme2510_int_read", " - PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()", " - media: marvell: Add check for clk_enable()", " - media: i2c: imx412: Add missing newline to prints", " - media: i2c: ov9282: Correct the exposure offset", " - media: mipi-csis: Add check for clk_enable()", " - media: camif-core: Add check for clk_enable()", " - media: uvcvideo: Propagate buf->error to userspace", " - mtd: hyperbus: Make hyperbus_unregister_device() return void", " - mtd: hyperbus: hbmc-am654: Convert to platform remove callback returning", " void", " - mtd: hyperbus: hbmc-am654: fix an OF node reference leak", " - staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()", " - scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1", " - scsi: ufs: bsg: Delete bsg_dev when setting up bsg fails", " - ocfs2: mark dquot as inactive if failed to start trans while releasing dquot", " - module: Extend the preempt disabled section in", " dereference_symbol_descriptor().", " - NFSv4.2: fix COPY_NOTIFY xdr buf size calculation", " - NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE", " - tools/bootconfig: Fix the wrong format specifier", " - xfrm: replay: Fix the update of replay_esn->oseq_hi for GSO", " - dmaengine: ti: edma: fix OF node reference leaks in edma_driver", " - gpio: mxc: remove dead code after switch to DT-only", " - net: fec: implement TSO descriptor cleanup", " - PM: hibernate: Add error handling for syscore_suspend()", " - net: netdevsim: try to close UDP port harness races", " - ptp: Properly handle compat ioctls", " - perf trace: Fix runtime error of index out of bounds", " - vsock: Allow retrying on connect() failure", " - bgmac: reduce max frame size to support just MTU 1500", " - net: sh_eth: Fix missing rtnl lock in suspend/resume path", " - net: hsr: fix fill_frame_info() regression vs VLAN packets", " - genksyms: fix memory leak when the same symbol is added from source", " - genksyms: fix memory leak when the same symbol is read from *.symref file", " - kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST", " - kconfig: add warn-unknown-symbols sanity check", " - kconfig: require a space after '#' for valid input", " - kconfig: remove unused code for S_DEF_AUTO in conf_read_simple()", " - kconfig: deduplicate code in conf_read_simple()", " - kconfig: WERROR unmet symbol dependency", " - kconfig: fix memory leak in sym_warn_unmet_dep()", " - hexagon: fix using plain integer as NULL pointer warning in cmpxchg", " - hexagon: Fix unbalanced spinlock in die()", " - f2fs: Introduce linear search for dentries", " - ktest.pl: Check kernelrelease return in get_version", " - ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro", " - drivers/card_reader/rtsx_usb: Restore interrupt based detection", " - usb: gadget: f_tcm: Fix Get/SetInterface return value", " - usb: dwc3: core: Defer the probe until USB power supply ready", " - usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to PD_T_SENDER_RESPONSE", " - usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS", " - btrfs: output the reason for open_ctree() failure", " - btrfs: fix data race when accessing the inode's disk_i_size at", " btrfs_drop_extents()", " - btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper error handling", " - sched: Don't try to catch up excess steal time.", " - lockdep: Fix upper limit for LOCKDEP_*_BITS configs", " - x86/amd_nb: Restrict init function to AMD-based systems", " - tun: fix group permission check", " - mmc: core: Respect quirk_max_rate for non-UHS SDIO card", " - mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id", " - HID: Wacom: Add PCI Wacom device support", " - net/mlx5: use do_aux_work for PHC overflow checks", " - wifi: iwlwifi: avoid memory leak", " - i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz", " - APEI: GHES: Have GHES honor the panic= setting", " - net: wwan: iosm: Fix hibernation by re-binding the driver around it", " - mmc: sdhci-msm: Correctly set the load for the regulator", " - tipc: re-order conditions in tipc_crypto_key_rcv()", " - selftests/net/ipsec: Fix Null pointer dereference in rtattr_pack()", " - Input: allocate keycode for phone linking", " - platform/x86: acer-wmi: Ignore AC events", " - x86/mm: Don't disable PCID when INVLPG has been fixed by microcode", " - usb: chipidea: ci_hdrc_imx: use dev_err_probe()", " - usb: chipidea/ci_hdrc_imx: Convert to platform remove callback returning", " void", " - usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in", " the error path of .probe()", " - net/ncsi: Add NC-SI 1.2 Get MC MAC Address command", " - net/ncsi: fix locking in Get MAC Address handling", " - xfs: report realtime block quota limits on realtime directories", " - xfs: don't over-report free space or inodes in statvfs", " - usb: xhci: Add timeout argument in address_device USB HCD callback", " - nvme: handle connectivity loss in nvme_set_queue_count", " - firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry", " - gpu: drm_dp_cec: fix broken CEC adapter properties check", " - tg3: Disable tg3 PCIe AER on system reboot", " - udp: gso: do not drop small packets when PMTU reduces", " - gpio: pca953x: Improve interrupt support", " - net: atlantic: fix warning during hot unplug", " - x86/xen: fix xen_hypercall_hvm() to not clobber %rbx", " - x86/xen: add FRAME_END to xen_hypercall_hvm()", " - tun: revert fix group permission check", " - cpufreq: s3c64xx: Fix compilation warning", " - leds: lp8860: Write full EEPROM, not only half of it", " - drm/modeset: Handle tiled displays in pan_display_atomic.", " - s390/futex: Fix FUTEX_OP_ANDN implementation", " - m68k: vga: Fix I/O defines", " - arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma", " - KVM: s390: vsie: fix some corner-cases when grabbing vsie pages", " - drm/amd/pm: Mark MM activity as unsupported", " - drm/komeda: Add check for komeda_get_layer_fourcc_list()", " - drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes", " - Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection", " - clk: sunxi-ng: a100: enable MMC clock reparenting", " - clk: qcom: clk-alpha-pll: fix alpha mode configuration", " - clk: qcom: gcc-mdm9607: Fix cmd_rcgr offset for blsp1_uart6 rcg", " - clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate", " - efi: libstub: Use '-std=gnu11' to fix build with GCC 15", " - perf bench: Fix undefined behavior in cmpworker()", " - of: Correct child specifier used as input of the 2nd nexus node", " - of: Fix of_find_node_opts_by_path() handling of alias+path+options", " - of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'", " - HID: hid-sensor-hub: don't use stale platform-data on remove", " - wifi: rtlwifi: rtl8821ae: Fix media status report", " - usb: gadget: f_tcm: Translate error to sense", " - usb: gadget: f_tcm: Decrement command ref count on cleanup", " - usb: gadget: f_tcm: ep_autoconfig with fullspeed endpoint", " - usb: gadget: f_tcm: Don't prepare BOT write request twice", " - serial: sh-sci: Drop __initdata macro for port_cfg", " - serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is", " in use", " - MIPS: Loongson64: remove ROM Size unit in boardinfo", " - powerpc/pseries/eeh: Fix get PE state translation", " - dm-crypt: don't update io->sector after kcryptd_crypt_write_io_submit()", " - dm-crypt: track tag_offset in convert_context", " - mips/math-emu: fix emulation of the prefx instruction", " - ALSA: hda/realtek: Enable headset mic on Positivo C6400", " - PCI: endpoint: Finish virtual EP removal in pci_epf_remove_vepf()", " - nvme-pci: Add TUXEDO InfinityFlex to Samsung sleep quirk", " - nvme-pci: Add TUXEDO IBP Gen9 to Samsung sleep quirk", " - scsi: qla2xxx: Move FCE Trace buffer allocation to user control", " - scsi: storvsc: Set correct data length for sending SCSI command without", " payload", " - kbuild: Move -Wenum-enum-conversion to W=2", " - x86/boot: Use '-std=gnu11' to fix build with GCC 15", " - arm64: dts: qcom: sm8350: Fix MPSS memory length", " - crypto: qce - fix priority to be less than ARMv8 CE", " - xfs: Add error handling for xfs_reflink_cancel_cow_range", " - media: ccs: Clean up parsed CCS static data on parse failure", " - iio: light: as73211: fix channel handling in only-color triggered buffer", " - soc: qcom: smem_state: fix missing of_node_put in error path", " - media: mc: fix endpoint iteration", " - media: ov5640: fix get_light_freq on auto", " - media: ccs: Fix CCS static data parsing for large block sizes", " - media: ccs: Fix cleanup order in ccs_probe()", " - media: uvcvideo: Fix event flags in uvc_ctrl_send_events", " - media: uvcvideo: Remove redundant NULL assignment", " - crypto: qce - fix goto jump in error path", " - crypto: qce - unregister previously registered algos in error path", " - nvmem: qcom-spmi-sdam: Set size in struct nvmem_config", " - nvmem: core: improve range check for nvmem_cell_write()", " - vfio/platform: check the bounds of read/write syscalls", " - pnfs/flexfiles: retry getting layout segment for reads", " - ocfs2: fix incorrect CPU endianness conversion causing mount failure", " - mtd: onenand: Fix uninitialized retlen in do_otp_read()", " - misc: fastrpc: Fix registered buffer page address", " - net/ncsi: wait for the last response to Deselect Package before configuring", " channel", " - net: phy: c45-tjaxx: add delay between MDIO write and read in soft_reset", " - MIPS: ftrace: Declare ftrace_get_parent_ra_addr() as static", " - net/ncsi: use dev_set_mac_address() for Get MC MAC Address handling", " - gpio: xilinx: remove excess kernel doc", " - memory: tegra20-emc: Correct memory device mask", " - ocfs2: check dir i_size in ocfs2_find_entry", " - mptcp: prevent excessive coalescing on receive", " - ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu()", " - drm/i915/selftests: avoid using uninitialized context", " - gpio: bcm-kona: Fix GPIO lock/unlock for banks above bank 0", " - gpio: bcm-kona: Make sure GPIO bits are unlocked when requesting IRQ", " - gpio: bcm-kona: Add missing newline to dev_err format string", " - xen: remove a confusing comment on auto-translated guest I/O", " - x86/xen: allow larger contiguous memory regions in PV guests", " - media: cxd2841er: fix 64-bit division on gcc-9", " - PCI/DPC: Quirk PIO log size for Intel Raptor Lake-P", " - vfio/pci: Enable iowrite64 and ioread64 for vfio pci", " - Grab mm lock before grabbing pt lock", " - x86/mm/tlb: Only trim the mm_cpumask once a second", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet 5V", " - batman-adv: Ignore neighbor throughput metrics in error case", " - perf/x86/intel: Ensure LBRs are disabled when a CPU is starting", " - usb: roles: set switch registered flag early on", " - usb: gadget: udc: renesas_usb3: Fix compiler warning", " - usb: dwc2: gadget: remove of_node reference upon udc_stop", " - USB: pci-quirks: Fix HCCPARAMS register error for LS7A EHCI", " - usb: core: fix pipe creation for get_bMaxPacketSize0", " - USB: quirks: add USB_QUIRK_NO_LPM quirk for Teclast dist", " - USB: Add USB_QUIRK_NO_LPM quirk for sony xperia xz1 smartphone", " - USB: cdc-acm: Fill in Renesas R-Car D3 USB Download mode quirk", " - usb: cdc-acm: Fix handling of oversized fragments", " - USB: serial: option: add MeiG Smart SLM828", " - USB: serial: option: add Telit Cinterion FN990B compositions", " - USB: serial: option: fix Telit Cinterion FN990A name", " - USB: serial: option: drop MeiG Smart defines", " - can: c_can: fix unbalanced runtime PM disable in error path", " - can: j1939: j1939_sk_send_loop(): fix unable to send messages with data", " length zero", " - alpha: make stack 16-byte aligned (most cases)", " - efi: Avoid cold plugged memory for placing the kernel", " - cgroup: fix race between fork and cgroup.kill", " - serial: 8250: Fix fifo underflow on flush", " - alpha: align stack for page fault and user unaligned trap handlers", " - gpio: stmpe: Check return value of stmpe_reg_read in", " stmpe_gpio_irq_sync_unlock", " - regmap-irq: Add missing kfree()", " - arm64: Handle .ARM.attributes section in linker scripts", " - mlxsw: Add return value check for mlxsw_sp_port_get_stats_raw()", " - btrfs: fix hole expansion when writing at an offset beyond EOF", " - clocksource: Replace cpumask_weight() with cpumask_empty()", " - clocksource: Use pr_info() for \"Checking clocksource synchronization\"", " message", " - ipv4: add RCU protection to ip4_dst_hoplimit()", " - net: treat possible_net_t net pointer as an RCU one and add read_pnet_rcu()", " - net: add dev_net_rcu() helper", " - ipv4: use RCU protection in rt_is_expired()", " - ipv4: use RCU protection in inet_select_addr()", " - Namespaceify min_pmtu sysctl", " - Namespaceify mtu_expires sysctl", " - selftest: net: Test IPv4 PMTU exceptions with DSCP and ECN", " - net: ipv4: Cache pmtu for all packet paths if multipath enabled", " - neighbour: delete redundant judgment statements", " - drm/tidss: Fix issue in irq handling causing irq-flood issue", " - drm/tidss: Clear the interrupt status for interrupts being disabled", " - kdb: Do not assume write() callback available", " - alpha: replace hardcoded stack offsets with autogenerated ones", " - nilfs2: do not output warnings when clearing dirty buffers", " - can: ems_pci: move ASIX AX99100 ids to pci_ids.h", " - serial: 8250_pci: add support for ASIX AX99100", " - parport_pc: add support for ASIX AX99100", " - netdevsim: print human readable IP address", " - selftests: rtnetlink: update netdevsim ipsec output format", " - ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus", " - x86/i8253: Disable PIT timer 0 when not in use", " - Revert \"btrfs: avoid monopolizing a core when activating a swap file\"", " - btrfs: avoid monopolizing a core when activating a swap file", " - arm64: mte: Do not allow PROT_MTE on MAP_HUGETLB user mappings", " - crypto: testmgr - fix wrong key length for pkcs1pad", " - crypto: testmgr - Fix wrong test case of RSA", " - crypto: testmgr - fix version number of RSA tests", " - crypto: testmgr - populate RSA CRT parameters in RSA test vectors", " - crypto: testmgr - some more fixes to RSA test vectors", " - mm: update mark_victim tracepoints fields", " - drm/probe-helper: Create a HPD IRQ event helper for a single connector", " - drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()", " - ASoC: renesas: rz-ssi: Add a check for negative sample_space", " - arm64: dts: mediatek: mt8183: Disable DSI display output by default", " - tpm: Use managed allocation for bios event log", " - kfence: allow use of a deferrable timer", " - [Config] updateconfigs to disable new KFENCE_DEFERRABLE", " - kfence: enable check kfence canary on panic via boot param", " - kfence: skip __GFP_THISNODE allocations on NUMA systems", " - soc: mediatek: mtk-devapc: Switch to devm_clk_get_enabled()", " - soc: mediatek: mtk-devapc: Fix leaking IO map on error paths", " - soc/mediatek: mtk-devapc: Convert to platform remove callback returning void", " - soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove", " - media: uvcvideo: Set error_idx during ctrl_commit errors", " - media: uvcvideo: Refactor iterators", " - media: uvcvideo: Only save async fh if success", " - batman-adv: Drop initialization of flexible ethtool_link_ksettings", " - usb: dwc3: Increase DWC3 controller halt timeout", " - usb: dwc3: Fix timeout issue during controller enter/exit from halt state", " - powerpc/64s/mm: Move __real_pte stubs into hash-4k.h", " - powerpc/64s: Rewrite __real_pte() and __rpte_to_hidx() as static inline", " - ALSA: hda/realtek: Fixup ALC225 depop procedure", " - geneve: Suppress list corruption splat in geneve_destroy_tunnels().", " - net: extract port range fields from fl_flow_key", " - flow_dissector: Fix handling of mixed port and port-range keys", " - flow_dissector: Fix port range key handling in BPF conversion", " - net: Add non-RCU dev_getbyhwaddr() helper", " - arp: switch to dev_getbyhwaddr() in arp_req_set_public()", " - power: supply: da9150-fg: fix potential overflow", " - nvme/ioctl: add missing space in err message", " - bpf: skip non exist keys in generic_map_lookup_batch", " - ALSA: hda/conexant: Add quirk for HP ProBook 450 G4 mute LED", " - acct: block access to kernel internal filesystems", " - mtd: rawnand: cadence: fix error code in cadence_nand_init()", " - mtd: rawnand: cadence: use dma_map_resource for sdma address", " - mtd: rawnand: cadence: fix incorrect device in dma_unmap_single", " - x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit", " - IB/mlx5: Set and get correct qp_num for a DCT QP", " - ovl: use wrappers to all vfs_*xattr() calls", " - ovl: pass ofs to creation operations", " - scsi: core: Don't memset() the entire scsi_cmnd in scsi_init_command()", " - scsi: core: Clear driver private data when retrying request", " - RDMA/mlx5: Fix bind QP error cleanup flow", " - sunrpc: suppress warnings for unused procfs functions", " - ALSA: usb-audio: Avoid dropping MIDI events at closing multiple ports", " - Bluetooth: L2CAP: Fix L2CAP_ECRED_CONN_RSP response", " - afs: remove variable nr_servers", " - afs: Make it possible to find the volumes that are using a server", " - afs: Fix the server_list to unuse a displaced server rather than putting it", " - net: loopback: Avoid sending IP packets without an Ethernet header", " - net: cadence: macb: Synchronize stats calculations", " - ASoC: es8328: fix route from DAC to output", " - ipvs: Always clear ipvs_property flag in skb_scrub_packet()", " - tcp: Defer ts_recent changes until req is owned", " - net: mvpp2: cls: Fixed Non IP flow, with vlan tag flow defination.", " - net/mlx5: IRQ, Fix null string in debug print", " - seg6: add support for SRv6 H.Encaps.Red behavior", " - seg6: add support for SRv6 H.L2Encaps.Red behavior", " - include: net: add static inline dst_dev_overhead() to dst.h", " - net: ipv6: seg6_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in seg6 lwt", " - net: ipv6: rpl_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in rpl lwt", " - x86/CPU: Fix warm boot hang regression on AMD SC1100 SoC systems", " - ftrace: Avoid potential division by zero in function_stat_show()", " - ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2", " - perf/core: Fix low freq setting via IOC_PERIOD", " - drm/amd/display: Fix HPD after gpu reset", " - net: enetc: fix the off-by-one issue in enetc_map_tx_buffs()", " - net: enetc: update UDP checksum when updating originTimestamp field", " - net: enetc: correct the xdp_tx statistics", " - phy: tegra: xusb: reset VBUS & ID OVERRIDE", " - phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk", " - vmlinux.lds: Ensure that const vars with relocations are mapped R/O", " - intel_idle: Handle older CPUs, which stop the TSC in deeper C states,", " correctly", " - drm/amdgpu: Check extended configuration space register when system uses", " large bar", " - drm/amdgpu: disable BAR resize on Dell G5 SE", " - Revert \"of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'\"", " - HID: appleir: Fix potential NULL dereference at raw event handle", " - gpio: rcar: Use raw_spinlock to protect register access", " - gpio: aggregator: protect driver attr handlers against module unload", " - ALSA: hda: intel: Add Dell ALC3271 to power_save denylist", " - ALSA: hda/realtek: update ALC222 depop optimize", " - drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress 200M", " - platform/x86: thinkpad_acpi: Add battery quirk for ThinkPad X131e", " - x86/cacheinfo: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Properly parse CPUID leaf 0x2 TLB descriptor 0x63", " - wifi: cfg80211: regulatory: improve invalid hints checking", " - wifi: nl80211: reject cooked mode if it is set along with other flags", " - rapidio: add check for rio_add_net() in rio_scan_alloc_net()", " - rapidio: fix an API misues when rio_add_net() fails", " - s390/traps: Fix test_monitor_call() inline assembly", " - block: fix conversion of GPT partition name to 7-bit", " - mm/page_alloc: fix uninitialized variable", " - mm: don't skip arch_sync_kernel_mappings() in error paths", " - wifi: iwlwifi: limit printed string from FW file", " - HID: google: fix unused variable warning under !CONFIG_ACPI", " - HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()", " - nvmet-tcp: Fix a possible sporadic response drops in weakly ordered arch", " - net: gso: fix ownership in __udp_gso_segment", " - caif_virtio: fix wrong pointer check in cfv_probe()", " - hwmon: (pmbus) Initialise page count in pmbus_identify()", " - hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor table", " - hwmon: (ad7314) Validate leading zero bits and return error", " - ALSA: usx2y: validate nrpacks module parameter on probe", " - llc: do not use skb_get() before dev_queue_xmit()", " - hwmon: fix a NULL vs IS_ERR_OR_NULL() check in xgene_hwmon_probe()", " - drm/sched: Fix preprocessor guard", " - be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink", " - net: hns3: make sure ptp clock is unregister and freed if", " hclge_ptp_get_cycle returns an error", " - ppp: Fix KMSAN uninit-value warning with bpf", " - vlan: enforce underlying device type", " - x86/sgx: Support loading enclave page without VMA permissions check", " - x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes()", " - x86/sgx: Export sgx_encl_{grow,shrink}()", " - x86/sgx: Support VA page allocation without reclaiming", " - x86/sgx: Fix size overflows in sgx_encl_create()", " - exfat: fix soft lockup in exfat_clear_bitmap", " - net-timestamp: support TCP GSO case for a few missing flags", " - sched/fair: Fix potential memory corruption in child_cfs_rq_on_list", " - net: ipv6: fix dst ref loop in ila lwtunnel", " - net: ipv6: fix missing dst ref drop in ila lwtunnel", " - gpio: rcar: Fix missing of_node_put() call", " - Revert \"drivers/card_reader/rtsx_usb: Restore interrupt based detection\"", " - usb: renesas_usbhs: Call clk_put()", " - usb: renesas_usbhs: Use devm_usb_get_phy()", " - usb: hub: lack of clearing xHC resources", " - usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass Storage Card Reader", " - usb: renesas_usbhs: Flush the notify_hotplug_work", " - usb: atm: cxacru: fix a flaw in existing endpoint checks", " - usb: dwc3: Set SUSPENDENABLE soon after phy init", " - usb: dwc3: gadget: Prevent irq storm when TH re-executes", " - usb: typec: ucsi: increase timeout for PPM reset operations", " - usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix functionality", " - usb: gadget: Set self-powered based on MaxPower and bmAttributes", " - usb: gadget: Fix setting self-powered state on suspend", " - usb: gadget: Check bmAttributes only if configuration is valid", " - xhci: pci: Fix indentation in the PCI device ID definitions", " - usb: xhci: Enable the TRB overfetch quirk on VIA VL805", " - mei: me: add panther lake P DID", " - intel_th: pci: Add Arrow Lake support", " - intel_th: pci: Add Panther Lake-H support", " - intel_th: pci: Add Panther Lake-P/U support", " - slimbus: messaging: Free transaction ID in delayed interrupt scenario", " - bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock", " - eeprom: digsy_mtc: Make GPIO lookup table match the device", " - drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl", " - media: uvcvideo: Avoid invalid memory access", " - media: uvcvideo: Avoid returning invalid controls", " - md: select BLOCK_LEGACY_AUTOLOAD", " - [Config] updateconfigs to select BLOCK_LEGACY_AUTOLOAD", " - mtd: rawnand: cadence: fix unchecked dereference", " - spi-mxs: Fix chipselect glitch", " - nilfs2: move page release outside of nilfs_delete_entry and nilfs_set_link", " - nilfs2: eliminate staggered calls to kunmap in nilfs_rename", " - bpf, vsock: Invoke proto::close on close()", " - kbuild: userprogs: use correct lld when linking through clang", " - net: ipv6: fix dst refleaks in rpl, seg6 and ioam6 lwtunnels", " - Linux 5.15.179", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21647", " - sched: sch_cake: add bounds checks to host bulk flow fairness counts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58002", " - media: uvcvideo: Remove dangling pointers", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58079", " - media: uvcvideo: Fix crash during unbind if gpio unit is in use", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21721", " - nilfs2: handle errors that nilfs_prepare_chunk() may return", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-26982", " - Squashfs: check the inode number is not the invalid value of zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21844", " - smb: client: Add check for next_buffer in receive_encrypted_standard()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58090", " - sched/core: Prevent rescheduling when interrupts are disabled", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21875", " - mptcp: always handle address removal under msk socket lock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21877", " - usbnet: gl620a: fix endpoint checking in genelink_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21878", " - i2c: npcm: disable interrupt enable bit before devm_request_irq", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21887", " - ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21846", " - acct: perform last write from workqueue", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21848", " - nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21862", " - drop_monitor: fix incorrect initialization order", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21871", " - tee: optee: Fix supplicant wait loop", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21865", " - gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21858", " - geneve: Fix use-after-free in geneve_find_dev().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21866", " - powerpc/code-patching: Fix KASAN hit by not flagging text patching area as", " VM_ALLOC", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21859", " - USB: gadget: f_midi: f_midi_complete to call queue_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21823", " - batman-adv: Drop unmanaged ELP metric worker", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58005", " - tpm: Change to kvalloc() in eventlog/acpi.c", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21748", " - ksmbd: fix integer overflows on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57977", " - memcg: fix soft lockup in the OOM process", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57978", " - media: imx-jpeg: Fix potential error pointer dereference in detach_pm()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57979", " - pps: Fix a use-after-free", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21811", " - nilfs2: protect access to buffers with no active references", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21722", " - nilfs2: do not force clear folio if buffer is referenced", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58086", " - drm/v3d: Stop active perfmon if it is being destroyed", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21758", " - ipv6: mcast: add RCU protection to mld_newpack()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21760", " - ndisc: extend RCU protection in ndisc_send_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21761", " - openvswitch: use RCU protection in ovs_vport_cmd_fill_info()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21762", " - arp: use RCU protection in arp_xmit()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21763", " - neighbour: use RCU protection in __neigh_notify()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21764", " - ndisc: use RCU protection in ndisc_alloc_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21765", " - ipv6: use RCU protection in ip6_default_advmss()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21766", " - ipv4: use RCU protection in __ip_rt_update_pmtu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21767", " - clocksource: Use migrate_disable() to avoid calling get_random_u32() in", " atomic context", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21772", " - partitions: mac: fix handling of bogus partition table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21704", " - usb: cdc-acm: Check control transfer buffer size before access", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21776", " - USB: hub: Ignore non-compliant devices with too many configs or interfaces", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21835", " - usb: gadget: f_midi: fix MIDI Streaming descriptor lengths", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21779", " - KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21781", " - batman-adv: fix panic during interface removal", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21782", " - orangefs: fix a oob in orangefs_debug_write", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57834", " - media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21785", " - arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21787", " - team: better TEAM_OPTION_TYPE_STRING validation", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21791", " - vrf: use RCU protection in l3mdev_l3_out()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58020", " - HID: multitouch: Add NULL check in mt_input_configured", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21795", " - NFSD: fix hang in nfsd4_shutdown_callback", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21796", " - nfsd: clear acl_access/acl_default after releasing them", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21820", " - tty: xilinx_uartps: split sysrq handling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21814", " - ptp: Ensure info->enable callback is always set", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21735", " - NFC: nci: Add bounds checking in nci_hci_create_pipe()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21736", " - nilfs2: fix possible int overflows in nilfs_fiemap()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58001", " - ocfs2: handle a symlink read error correctly", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58007", " - soc: qcom: socinfo: Avoid out of bounds read of serial number", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21744", " - wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21745", " - blk-cgroup: Fix class @block_class's subsystem refcount leakage", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58076", " - clk: qcom: gcc-sm6350: Add missing parent_map for two clocks", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58083", " - KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58010", " - binfmt_flat: Fix integer overflow bug on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21749", " - net: rose: lock the socket in rose_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57981", " - usb: xhci: Fix NULL pointer dereference on certain command aborts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21684", " - gpio: xilinx: Convert gpio_lock to raw spinlock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58085", " - tomoyo: don't emit warning in tomoyo_write_control()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58014", " - wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58016", " - safesetid: check size of policy writes", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58017", " - printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21753", " - btrfs: fix use-after-free when attempting to join an aborted transaction", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58055", " - usb: gadget: f_tcm: Don't free command immediately", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57980", " - media: uvcvideo: Fix double free in error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21707", " - mptcp: consolidate suboption status", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21708", " - net: usb: rtl8150: enable basic endpoint checking", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21826", " - netfilter: nf_tables: reject mismatching sum of field_len with set key", " length", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21715", " - net: davicom: fix UAF in dm9000_drv_remove", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21718", " - net: rose: fix timer races against user threads", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21719", " - ipmr: do not call mr_mfc_uses_dev() for unres entries", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21802", " - net: hns3: fix oops when unload drivers paralleling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58058", " - ubifs: skip dumping tnc tree when zroot is null", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58069", " - rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21804", " - PCI: rcar-ep: Fix incorrect variable used when calling", " devm_request_mem_region()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58034", " - memory: tegra20-emc: fix an OF node reference bug in", " tegra_emc_find_node_by_ram_code()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57973", " - rdma/cxgb4: Prevent potential integer overflow on 32bit", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21726", " - padata: avoid UAF for reorder_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21727", " - padata: fix UAF in padata_reorder", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21728", " - bpf: Send signals asynchronously if !preemptible", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21711", " - net/rose: prevent integer overflows in rose_setsockopt()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21799", " - net: ethernet: ti: am65-cpsw: fix freeing IRQ in", " am65_cpsw_nuss_remove_tx_chns()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21806", " - net: let net.core.dev_weight always be non-zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21830", " - landlock: Handle weird files", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58071", " - team: prevent adding a device which is already a team device lower", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58063", " - wifi: rtlwifi: fix memory leaks and invalid access at probe error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58072", " - wifi: rtlwifi: remove unused check_buddy_priv", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58051", " - ipmi: ipmb: Add check devm_kasprintf() returned value", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58052", " - drm/amdgpu: Fix potential NULL pointer dereference in", " atomctrl_get_smc_sclk_range_table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57986", " - HID: core: Fix assumption that Resolution Multipliers must be in Logical", " Collections", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21731", " - nbd: don't allow reconnect after disconnect", " * Fix bugs preventing boot on Intel TDX-enabled hosts (LP: #2097811)", " - x86/mtrr: Remove physical address size calculation", " * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport", " (LP: #2104380)", " - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n", " * nfsd hangs and never recovers after NFS4ERR_DELAY and a connection loss", " (LP: #2103564)", " - NFSD: Reset cb_seq_status after NFS4ERR_DELAY", " * kernel hard lockup in cgroups during eBPF workload (LP: #2089318)", " - cgroup: cgroup: Honor caller's cgroup NS when resolving cgroup id", " - cgroup: Homogenize cgroup_get_from_id() return value", " - cgroup: Make cgroup_get_from_id() prettier", " - cgroup.c: add helper __cset_cgroup_from_root to cleanup duplicated codes", " - cgroup: Reorganize css_set_lock and kernfs path processing", " * CVE-2023-52664", " - net: atlantic: eliminate double free in error handling logic", " * CVE-2023-52927", " - netfilter: allow exp not to be removed in nf_ct_find_expectation", "" ], "package": "linux-kvm", "version": "5.15.0-1080.85", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 09:33:48 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1080 version '5.15.0-1080.85' (source package linux-kvm version '5.15.0-1080.85') was added. linux-kvm-headers-5.15.0-1080 version '5.15.0-1080.85' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1079-kvm. As such we can use the source package version of the removed package, '5.15.0-1079.84', 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-5.15.0-1080-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1080.85", "version": "5.15.0-1080.85" }, "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "changes": [ { "cves": [ { "cve": "CVE-2025-21971", "url": "https://ubuntu.com/security/CVE-2025-21971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56599", "url": "https://ubuntu.com/security/CVE-2024-56599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "cve_priority": "low", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2024-56721", "url": "https://ubuntu.com/security/CVE-2024-56721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Terminate the erratum_1386_microcode array The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end.", "cve_priority": "medium", "cve_public_date": "2024-12-29 12:15:00 UTC" }, { "cve": "CVE-2025-21647", "url": "https://ubuntu.com/security/CVE-2025-21647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error). As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.", "cve_priority": "medium", "cve_public_date": "2025-01-19 11:15:00 UTC" }, { "cve": "CVE-2024-58002", "url": "https://ubuntu.com/security/CVE-2024-58002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58079", "url": "https://ubuntu.com/security/CVE-2024-58079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix crash during unbind if gpio unit is in use We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device. If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled. If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS. We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete. Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21721", "url": "https://ubuntu.com/security/CVE-2025-21721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle errors that nilfs_prepare_chunk() may return Patch series \"nilfs2: fix issues with rename operations\". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename().", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26982", "url": "https://ubuntu.com/security/CVE-2024-26982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk", "cve_priority": "medium", "cve_public_date": "2024-05-01 06:15:00 UTC" }, { "cve": "CVE-2025-21844", "url": "https://ubuntu.com/security/CVE-2025-21844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2024-58090", "url": "https://ubuntu.com/security/CVE-2024-58090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched().", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21875", "url": "https://ubuntu.com/security/CVE-2025-21875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock. The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications. The above statement is incorrect, as without locks another process could concur ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21877", "url": "https://ubuntu.com/security/CVE-2025-21877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21878", "url": "https://ubuntu.com/security/CVE-2025-21878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer. Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only. Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21887", "url": "https://ubuntu.com/security/CVE-2025-21887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... ", "cve_priority": "medium", "cve_public_date": "2025-03-27 15:15:00 UTC" }, { "cve": "CVE-2025-21846", "url": "https://ubuntu.com/security/CVE-2025-21846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21848", "url": "https://ubuntu.com/security/CVE-2025-21848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21862", "url": "https://ubuntu.com/security/CVE-2025-21862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21871", "url": "https://ubuntu.com/security/CVE-2025-21871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover.", "cve_priority": "medium", "cve_public_date": "2025-03-27 14:15:00 UTC" }, { "cve": "CVE-2025-21865", "url": "https://ubuntu.com/security/CVE-2025-21865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 (\"gtp: Destroy device along with udp socket's netns dismantle.\") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21858", "url": "https://ubuntu.com/security/CVE-2025-21858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21866", "url": "https://ubuntu.com/security/CVE-2025-21866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b (\"mm, kasan, kmsan: instrument copy_from/to_kernel_nofault\") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21859", "url": "https://ubuntu.com/security/CVE-2025-21859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.", "cve_priority": "medium", "cve_public_date": "2025-03-12 10:15:00 UTC" }, { "cve": "CVE-2025-21823", "url": "https://ubuntu.com/security/CVE-2025-21823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: Drop unmanaged ELP metric worker The ELP worker needs to calculate new metric values for all neighbors \"reachable\" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context. Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses. Directly canceling the metric worker also has various problems: * cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish. * iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must \"stop\" all still running workers) The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by: * creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context * only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58005", "url": "https://ubuntu.com/security/CVE-2024-58005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21748", "url": "https://ubuntu.com/security/CVE-2025-21748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57977", "url": "https://ubuntu.com/security/CVE-2024-57977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57978", "url": "https://ubuntu.com/security/CVE-2024-57978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Fix potential error pointer dereference in detach_pm() The proble is on the first line: \tif (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-57979", "url": "https://ubuntu.com/security/CVE-2024-57979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 (\"pps: Fix a use-after free bug when unregistering a source.\"), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2025-21811", "url": "https://ubuntu.com/security/CVE-2025-21811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21722", "url": "https://ubuntu.com/security/CVE-2025-21722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series \"nilfs2: protect busy buffer heads from being force-cleared\". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-58086", "url": "https://ubuntu.com/security/CVE-2024-58086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop active perfmon if it is being destroyed If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 (\"drm/v3d: Stop the active perfmon before being destroyed\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-21758", "url": "https://ubuntu.com/security/CVE-2025-21758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21760", "url": "https://ubuntu.com/security/CVE-2025-21760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21761", "url": "https://ubuntu.com/security/CVE-2025-21761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21762", "url": "https://ubuntu.com/security/CVE-2025-21762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21763", "url": "https://ubuntu.com/security/CVE-2025-21763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21764", "url": "https://ubuntu.com/security/CVE-2025-21764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21765", "url": "https://ubuntu.com/security/CVE-2025-21765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21766", "url": "https://ubuntu.com/security/CVE-2025-21766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21767", "url": "https://ubuntu.com/security/CVE-2025-21767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context The following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0 It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context. Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21772", "url": "https://ubuntu.com/security/CVE-2025-21772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21704", "url": "https://ubuntu.com/security/CVE-2025-21704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 (\"cdc-acm: reassemble fragmented notifications\"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.", "cve_priority": "medium", "cve_public_date": "2025-02-22 10:15:00 UTC" }, { "cve": "CVE-2025-21776", "url": "https://ubuntu.com/security/CVE-2025-21776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21835", "url": "https://ubuntu.com/security/CVE-2025-21835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of \"in\" and \"out\" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that \"in\" ports send data to the host and \"out\" ports receive data from it.", "cve_priority": "medium", "cve_public_date": "2025-03-07 09:15:00 UTC" }, { "cve": "CVE-2025-21779", "url": "https://ubuntu.com/security/CVE-2025-21779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21781", "url": "https://ubuntu.com/security/CVE-2025-21781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21782", "url": "https://ubuntu.com/security/CVE-2025-21782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57834", "url": "https://ubuntu.com/security/CVE-2024-57834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21785", "url": "https://ubuntu.com/security/CVE-2025-21785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21787", "url": "https://ubuntu.com/security/CVE-2025-21787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21791", "url": "https://ubuntu.com/security/CVE-2025-21791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58020", "url": "https://ubuntu.com/security/CVE-2024-58020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Add NULL check in mt_input_configured devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21795", "url": "https://ubuntu.com/security/CVE-2025-21795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: fix hang in nfsd4_shutdown_callback If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped. This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21796", "url": "https://ubuntu.com/security/CVE-2025-21796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21820", "url": "https://ubuntu.com/security/CVE-2025-21820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() \t\t\t cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21814", "url": "https://ubuntu.com/security/CVE-2025-21814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21735", "url": "https://ubuntu.com/security/CVE-2025-21735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The \"pipe\" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21736", "url": "https://ubuntu.com/security/CVE-2025-21736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58001", "url": "https://ubuntu.com/security/CVE-2024-58001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series \"Convert ocfs2 to use folios\". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58007", "url": "https://ubuntu.com/security/CVE-2024-58007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21744", "url": "https://ubuntu.com/security/CVE-2025-21744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21745", "url": "https://ubuntu.com/security/CVE-2025-21745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit().", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58076", "url": "https://ubuntu.com/security/CVE-2024-58076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58083", "url": "https://ubuntu.com/security/CVE-2024-58083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is \"bad\", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 (\"KVM: Convert the kvm->vcpus array to a xarray\")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 (\"KVM: Fix vcpu_array[0] races\") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58010", "url": "https://ubuntu.com/security/CVE-2024-58010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The \"relocs\" count needs to be checked as well. Otherwise on 32bit systems the calculation of \"full_data\" could be wrong. \tfull_data = data_len + relocs * sizeof(unsigned long);", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21749", "url": "https://ubuntu.com/security/CVE-2025-21749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-57981", "url": "https://ubuntu.com/security/CVE-2024-57981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21684", "url": "https://ubuntu.com/security/CVE-2025-21684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)", "cve_priority": "medium", "cve_public_date": "2025-02-09 12:15:00 UTC" }, { "cve": "CVE-2024-58085", "url": "https://ubuntu.com/security/CVE-2024-58085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tomoyo: don't emit warning in tomoyo_write_control() syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the \"too small to fail\" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58014", "url": "https://ubuntu.com/security/CVE-2024-58014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58016", "url": "https://ubuntu.com/security/CVE-2024-58016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: safesetid: check size of policy writes syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. [PM: subject tweak]", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58017", "url": "https://ubuntu.com/security/CVE-2024-58017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2025-21753", "url": "https://ubuntu.com/security/CVE-2025-21753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2024-58055", "url": "https://ubuntu.com/security/CVE-2024-58055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57980", "url": "https://ubuntu.com/security/CVE-2024-57980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21707", "url": "https://ubuntu.com/security/CVE-2025-21707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21708", "url": "https://ubuntu.com/security/CVE-2025-21708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21826", "url": "https://ubuntu.com/security/CVE-2025-21826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject mismatching sum of field_len with set key length The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21715", "url": "https://ubuntu.com/security/CVE-2025-21715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 (\"net: qcom/emac: fix UAF in emac_remove\"). This bug is detected by our static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21718", "url": "https://ubuntu.com/security/CVE-2025-21718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21719", "url": "https://ubuntu.com/security/CVE-2025-21719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: do not call mr_mfc_uses_dev() for unres entries syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to \"struct sk_buff_head unresolved\", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21802", "url": "https://ubuntu.com/security/CVE-2025-21802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process.", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58058", "url": "https://ubuntu.com/security/CVE-2024-58058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58069", "url": "https://ubuntu.com/security/CVE-2024-58069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2025-21804", "url": "https://ubuntu.com/security/CVE-2025-21804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-58034", "url": "https://ubuntu.com/security/CVE-2024-58034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the \"emc-tables\" node is always device's child node with the property \"nvidia,use-ram-code\", and the \"lpddr2\" node is a child of the \"emc-tables\" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2024-57973", "url": "https://ubuntu.com/security/CVE-2024-57973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The \"gl->tot_len\" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the \"gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)\" addition could have an integer wrapping bug. Use size_add() to prevent this.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21726", "url": "https://ubuntu.com/security/CVE-2025-21726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request\t\t\tcrypto_request\t\tcrypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } \t\t\t\tpadata_do_serial \t\t\t\t // new request added \t\t\t\t list_add // sees the new request queue_work(reorder_work) \t\t\t\t padata_reorder \t\t\t\t queue_work_on(squeue->work) ... \t\t\t\t \t\t\t\tpadata_serial_worker \t\t\t\t// completes new request, \t\t\t\t// no more outstanding \t\t\t\t// requests \t\t\t\t\t\t\tcrypto_del_alg \t\t\t\t\t\t\t // free pd invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21727", "url": "https://ubuntu.com/security/CVE-2025-21727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker\t\t\t\tcrypto_del_alg padata_put_pd_cnt // sub refcnt \t\t\t\t\t\tpadata_free_shell \t\t\t\t\t\tpadata_put_pd(ps->pd); \t\t\t\t\t\t// pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21728", "url": "https://ubuntu.com/security/CVE-2025-21728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21711", "url": "https://ubuntu.com/security/CVE-2025-21711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21799", "url": "https://ubuntu.com/security/CVE-2025-21799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21806", "url": "https://ubuntu.com/security/CVE-2025-21806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\ \treturned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\ \tnext=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\ \t__list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced).", "cve_priority": "medium", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-21830", "url": "https://ubuntu.com/security/CVE-2025-21830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2024-58071", "url": "https://ubuntu.com/security/CVE-2024-58071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58063", "url": "https://ubuntu.com/security/CVE-2024-58063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f (\"wireless: rtlwifi: remove unnecessary pci_set_drvdata()\") and commit 3d86b93064c7 (\"rtlwifi: Fix PCI probe error path orphaned memory\").", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58072", "url": "https://ubuntu.com/security/CVE-2024-58072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f (\"rtlwifi: Update header file\") introduced a global list of private data structures. Later on, commit 26634c4b1868 (\"rtlwifi Modify existing bits to match vendor version 2013.02.07\") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58051", "url": "https://ubuntu.com/security/CVE-2024-58051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: Add check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-58052", "url": "https://ubuntu.com/security/CVE-2024-58052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.", "cve_priority": "medium", "cve_public_date": "2025-03-06 16:15:00 UTC" }, { "cve": "CVE-2024-57986", "url": "https://ubuntu.com/security/CVE-2024-57986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b (\"HID: core: Fix deadloop in hid_apply_multiplier.\"), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: \t * \"The Resolution Multiplier control must be contained in the same \t * Logical Collection as the control(s) to which it is to be applied. \t ... \t * If no Logical Collection is \t * defined, the Resolution Multiplier is associated with all \t * controls in the report.\" \t * HID Usage Table, v1.12, Section 4.3.1, p30 \t * \t * Thus, search from the current collection upwards until we find a \t * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2025-21731", "url": "https://ubuntu.com/security/CVE-2025-21731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2024-26837", "url": "https://ubuntu.com/security/CVE-2024-26837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.", "cve_priority": "medium", "cve_public_date": "2024-04-17 10:15:00 UTC" }, { "cve": "CVE-2023-52664", "url": "https://ubuntu.com/security/CVE-2023-52664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.", "cve_priority": "high", "cve_public_date": "2024-05-17 14:15:00 UTC" }, { "cve": "CVE-2023-52927", "url": "https://ubuntu.com/security/CVE-2023-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.", "cve_priority": "high", "cve_public_date": "2025-03-14 15:15:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1080.85 -proposed tracker (LP: #2106968)", "", " [ Ubuntu: 5.15.0-140.150 ]", "", " * jammy/linux: 5.15.0-140.150 -proposed tracker (LP: #2106996)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.04.14)", " * NFS, overlay, fstab issue after update to kernel 5.15.0-133-generic and -134", " (LP: #2103598)", " - udf: Fix directory iteration for longer tail extents", " * Remove floppy kernel module causes null pointer deference (LP: #2104326)", " - floppy: fix add_disk() assumption on exit due to new developments", " * CVE-2025-21971", " - net_sched: Prevent creation of classes with TC_H_ROOT", " * CVE-2024-56599", " - wifi: ath10k: avoid NULL pointer error during sdio remove", " * CVE-2024-56721", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026)", " - afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY", " - afs: Fix directory format encoding struct", " - hung_task: move hung_task sysctl interface to hung_task.c", " - sysctl: use const for typically used max/min proc sysctls", " - sysctl: share unsigned long const values", " - fs: move inode sysctls to its own file", " - fs: move fs stat sysctls to file_table.c", " - fs: fix proc_handler for sysctl_nr_open", " - block: deprecate autoloading based on dev_t", " - block: retry call probe after request_module in blk_request_module", " - pstore/blk: trivial typo fixes", " - nvme: Add error check for xa_store in nvme_get_effects_log", " - partitions: ldm: remove the initial kernel-doc notation", " - select: Fix unbalanced user_access_end()", " - afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call", " - sched/psi: Use task->psi_flags to clear in CPU migration", " - sched/fair: Fix value reported by hot tasks pulled in /proc/schedstat", " - drm/etnaviv: Fix page property being used for non writecombine buffers", " - genirq: Make handle_enforce_irqctx() unconditionally available", " - wifi: rtlwifi: do not complete firmware loading needlessly", " - wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last step", " - wifi: rtlwifi: wait for firmware loading before releasing memory", " - wifi: rtlwifi: fix init_sw_vars leak when probe fails", " - wifi: rtlwifi: usb: fix workqueue leak when probe fails", " - spi: zynq-qspi: Add check for clk_enable()", " - dt-bindings: mmc: controller: clarify the address-cells description", " - spi: dt-bindings: add schema listing peripheral-specific properties", " - dt-bindings: Another pass removing cases of 'allOf' containing a '$ref'", " - dt-bindings: leds: Add Qualcomm Light Pulse Generator binding", " - dt-bindings: leds: Optional multi-led unit address", " - dt-bindings: leds: Add multicolor PWM LED bindings", " - dt-bindings: leds: class-multicolor: reference class directly in multi-led", " node", " - dt-bindings: leds: class-multicolor: Fix path to color definitions", " - rtlwifi: replace usage of found with dedicated list iterator variable", " - wifi: rtlwifi: remove unused timer and related code", " - wifi: rtlwifi: remove unused dualmac control leftovers", " - wifi: rtlwifi: destroy workqueue at rtl_deinit_core", " - wifi: rtlwifi: pci: wait for firmware loading before releasing memory", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - Revert \"HID: multitouch: Add support for lenovo Y9000P Touchpad\"", " - HID: multitouch: fix support for Goodix PID 0x01e9", " - regulator: dt-bindings: mt6315: Drop regulator-compatible property", " - ACPI: fan: cleanup resources in the error path of .probe()", " - cpupower: fix TSC MHz calculation", " - dt-bindings: mfd: bd71815: Fix rsense and typos", " - leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata()", " - cpufreq: schedutil: Fix superfluous updates caused by need_freq_update", " - clk: imx8mp: Fix clkout1/2 support", " - regulator: of: Implement the unwind path of of_regulator_match()", " - samples/landlock: Fix possible NULL dereference in parse_path()", " - wifi: wlcore: fix unbalanced pm_runtime calls", " - net/smc: fix data error when recvmsg with MSG_PEEK flag", " - landlock: Move filesystem helpers and add a new one", " - wifi: mt76: mt76u_vendor_request: Do not print error messages when -EPROTO", " - cpufreq: ACPI: Fix max-frequency computation", " - selftests: harness: fix printing of mismatch values in __EXPECT()", " - wifi: cfg80211: Handle specific BSSID in 6GHz scanning", " - wifi: cfg80211: adjust allocation of colocated AP data", " - clk: analogbits: Fix incorrect calculation of vco rate delta", " - selftests/landlock: Fix error message", " - net/mlxfw: Drop hard coded max FW flash image size", " - netfilter: nft_flow_offload: update tcp state flags under lock", " - tcp_cubic: fix incorrect HyStart round start detection", " - tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind", " - libbpf: Fix segfault due to libelf functions not setting errno", " - ASoC: sun4i-spdif: Add clock multiplier settings", " - perf header: Fix one memory leakage in process_bpf_btf()", " - perf header: Fix one memory leakage in process_bpf_prog_info()", " - perf bpf: Fix two memory leakages when calling", " perf_env__insert_bpf_prog_info()", " - ASoC: renesas: rz-ssi: Use only the proper amount of dividers", " - ktest.pl: Remove unused declarations in run_bisect_test function", " - crypto: hisilicon/sec - add some comments for soft fallback", " - crypto: hisilicon/sec - delete redundant blank lines", " - crypto: hisilicon/sec2 - optimize the error return process", " - crypto: hisilicon/sec2 - fix for aead icv error", " - crypto: hisilicon/sec2 - fix for aead invalid authsize", " - crypto: ixp4xx - fix OF node reference leaks in init_ixp_crypto()", " - padata: fix sysfs store callback check", " - perf top: Don't complain about lack of vmlinux when not resolving some", " kernel samples", " - perf report: Fix misleading help message about --demangle", " - padata: add pd get/put refcnt helper", " - ARM: at91: pm: change BU Power Switch to automatic mode", " - arm64: dts: mt8183: set DMIC one-wire mode on Damu", " - arm64: dts: mediatek: mt8516: fix GICv2 range", " - arm64: dts: mediatek: mt8516: fix wdt irq type", " - arm64: dts: mediatek: mt8516: remove 2 invalid i2c clocks", " - arm64: dts: mediatek: mt8516: add i2c clock-div property", " - arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A", " - RDMA/mlx4: Avoid false error about access to uninitialized gids array", " - arm64: dts: mediatek: mt8173-evb: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Drop regulator-compatible property", " - arm64: dts: mediatek: mt8173-elm: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8173-evb: Fix MT6397 PMIC sub-node names", " - arm64: dts: mediatek: mt8183: kenzo: Support second source touchscreen", " - arm64: dts: mediatek: mt8183: willow: Support second source touchscreen", " - memory: Add LPDDR2-info helpers", " - memory: tegra20-emc: Support matching timings by LPDDR2 configuration", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Drop pp3300_panel voltage", " settings", " - arm64: dts: qcom: msm8996: Fix up USB3 interrupts", " - arm64: dts: qcom: msm8994: Describe USB interrupts", " - arm64: dts: qcom: msm8916: correct sleep clock frequency", " - arm64: dts: qcom: msm8994: correct sleep clock frequency", " - arm64: dts: qcom: sc7280: correct sleep clock frequency", " - arm64: dts: qcom: sm6125: correct sleep clock frequency", " - arm64: dts: qcom: sm8250: correct sleep clock frequency", " - arm64: dts: qcom: sm8350: correct sleep clock frequency", " - arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280", " properties", " - arm64: dts: qcom: sdm845: Fix interrupt types of camss interrupts", " - ARM: dts: mediatek: mt7623: fix IR nodename", " - fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device()", " - RDMA/mlx5: Remove iova from struct mlx5_core_mkey", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - RDMA/mlx5: Fix indirect mkey ODP page count", " - xen/x86: free_p2m_page: use memblock_free_ptr() to free a virtual pointer", " - memblock: drop memblock_free_early_nid() and memblock_free_early()", " - of: reserved-memory: Do not make kmemleak ignore freed address", " - efi: sysfb_efi: fix W=1 warnings when EFI is not set", " - media: rc: iguanair: handle timeouts", " - media: lmedm04: Handle errors for lme2510_int_read", " - PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()", " - media: marvell: Add check for clk_enable()", " - media: i2c: imx412: Add missing newline to prints", " - media: i2c: ov9282: Correct the exposure offset", " - media: mipi-csis: Add check for clk_enable()", " - media: camif-core: Add check for clk_enable()", " - media: uvcvideo: Propagate buf->error to userspace", " - mtd: hyperbus: Make hyperbus_unregister_device() return void", " - mtd: hyperbus: hbmc-am654: Convert to platform remove callback returning", " void", " - mtd: hyperbus: hbmc-am654: fix an OF node reference leak", " - staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()", " - scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1", " - scsi: ufs: bsg: Delete bsg_dev when setting up bsg fails", " - ocfs2: mark dquot as inactive if failed to start trans while releasing dquot", " - module: Extend the preempt disabled section in", " dereference_symbol_descriptor().", " - NFSv4.2: fix COPY_NOTIFY xdr buf size calculation", " - NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE", " - tools/bootconfig: Fix the wrong format specifier", " - xfrm: replay: Fix the update of replay_esn->oseq_hi for GSO", " - dmaengine: ti: edma: fix OF node reference leaks in edma_driver", " - gpio: mxc: remove dead code after switch to DT-only", " - net: fec: implement TSO descriptor cleanup", " - PM: hibernate: Add error handling for syscore_suspend()", " - net: netdevsim: try to close UDP port harness races", " - ptp: Properly handle compat ioctls", " - perf trace: Fix runtime error of index out of bounds", " - vsock: Allow retrying on connect() failure", " - bgmac: reduce max frame size to support just MTU 1500", " - net: sh_eth: Fix missing rtnl lock in suspend/resume path", " - net: hsr: fix fill_frame_info() regression vs VLAN packets", " - genksyms: fix memory leak when the same symbol is added from source", " - genksyms: fix memory leak when the same symbol is read from *.symref file", " - kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST", " - kconfig: add warn-unknown-symbols sanity check", " - kconfig: require a space after '#' for valid input", " - kconfig: remove unused code for S_DEF_AUTO in conf_read_simple()", " - kconfig: deduplicate code in conf_read_simple()", " - kconfig: WERROR unmet symbol dependency", " - kconfig: fix memory leak in sym_warn_unmet_dep()", " - hexagon: fix using plain integer as NULL pointer warning in cmpxchg", " - hexagon: Fix unbalanced spinlock in die()", " - f2fs: Introduce linear search for dentries", " - ktest.pl: Check kernelrelease return in get_version", " - ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro", " - drivers/card_reader/rtsx_usb: Restore interrupt based detection", " - usb: gadget: f_tcm: Fix Get/SetInterface return value", " - usb: dwc3: core: Defer the probe until USB power supply ready", " - usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to PD_T_SENDER_RESPONSE", " - usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS", " - btrfs: output the reason for open_ctree() failure", " - btrfs: fix data race when accessing the inode's disk_i_size at", " btrfs_drop_extents()", " - btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper error handling", " - sched: Don't try to catch up excess steal time.", " - lockdep: Fix upper limit for LOCKDEP_*_BITS configs", " - x86/amd_nb: Restrict init function to AMD-based systems", " - tun: fix group permission check", " - mmc: core: Respect quirk_max_rate for non-UHS SDIO card", " - mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id", " - HID: Wacom: Add PCI Wacom device support", " - net/mlx5: use do_aux_work for PHC overflow checks", " - wifi: iwlwifi: avoid memory leak", " - i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz", " - APEI: GHES: Have GHES honor the panic= setting", " - net: wwan: iosm: Fix hibernation by re-binding the driver around it", " - mmc: sdhci-msm: Correctly set the load for the regulator", " - tipc: re-order conditions in tipc_crypto_key_rcv()", " - selftests/net/ipsec: Fix Null pointer dereference in rtattr_pack()", " - Input: allocate keycode for phone linking", " - platform/x86: acer-wmi: Ignore AC events", " - x86/mm: Don't disable PCID when INVLPG has been fixed by microcode", " - usb: chipidea: ci_hdrc_imx: use dev_err_probe()", " - usb: chipidea/ci_hdrc_imx: Convert to platform remove callback returning", " void", " - usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in", " the error path of .probe()", " - net/ncsi: Add NC-SI 1.2 Get MC MAC Address command", " - net/ncsi: fix locking in Get MAC Address handling", " - xfs: report realtime block quota limits on realtime directories", " - xfs: don't over-report free space or inodes in statvfs", " - usb: xhci: Add timeout argument in address_device USB HCD callback", " - nvme: handle connectivity loss in nvme_set_queue_count", " - firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry", " - gpu: drm_dp_cec: fix broken CEC adapter properties check", " - tg3: Disable tg3 PCIe AER on system reboot", " - udp: gso: do not drop small packets when PMTU reduces", " - gpio: pca953x: Improve interrupt support", " - net: atlantic: fix warning during hot unplug", " - x86/xen: fix xen_hypercall_hvm() to not clobber %rbx", " - x86/xen: add FRAME_END to xen_hypercall_hvm()", " - tun: revert fix group permission check", " - cpufreq: s3c64xx: Fix compilation warning", " - leds: lp8860: Write full EEPROM, not only half of it", " - drm/modeset: Handle tiled displays in pan_display_atomic.", " - s390/futex: Fix FUTEX_OP_ANDN implementation", " - m68k: vga: Fix I/O defines", " - arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma", " - KVM: s390: vsie: fix some corner-cases when grabbing vsie pages", " - drm/amd/pm: Mark MM activity as unsupported", " - drm/komeda: Add check for komeda_get_layer_fourcc_list()", " - drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes", " - Bluetooth: L2CAP: accept zero as a special value for MTU auto-selection", " - clk: sunxi-ng: a100: enable MMC clock reparenting", " - clk: qcom: clk-alpha-pll: fix alpha mode configuration", " - clk: qcom: gcc-mdm9607: Fix cmd_rcgr offset for blsp1_uart6 rcg", " - clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate", " - efi: libstub: Use '-std=gnu11' to fix build with GCC 15", " - perf bench: Fix undefined behavior in cmpworker()", " - of: Correct child specifier used as input of the 2nd nexus node", " - of: Fix of_find_node_opts_by_path() handling of alias+path+options", " - of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'", " - HID: hid-sensor-hub: don't use stale platform-data on remove", " - wifi: rtlwifi: rtl8821ae: Fix media status report", " - usb: gadget: f_tcm: Translate error to sense", " - usb: gadget: f_tcm: Decrement command ref count on cleanup", " - usb: gadget: f_tcm: ep_autoconfig with fullspeed endpoint", " - usb: gadget: f_tcm: Don't prepare BOT write request twice", " - serial: sh-sci: Drop __initdata macro for port_cfg", " - serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is", " in use", " - MIPS: Loongson64: remove ROM Size unit in boardinfo", " - powerpc/pseries/eeh: Fix get PE state translation", " - dm-crypt: don't update io->sector after kcryptd_crypt_write_io_submit()", " - dm-crypt: track tag_offset in convert_context", " - mips/math-emu: fix emulation of the prefx instruction", " - ALSA: hda/realtek: Enable headset mic on Positivo C6400", " - PCI: endpoint: Finish virtual EP removal in pci_epf_remove_vepf()", " - nvme-pci: Add TUXEDO InfinityFlex to Samsung sleep quirk", " - nvme-pci: Add TUXEDO IBP Gen9 to Samsung sleep quirk", " - scsi: qla2xxx: Move FCE Trace buffer allocation to user control", " - scsi: storvsc: Set correct data length for sending SCSI command without", " payload", " - kbuild: Move -Wenum-enum-conversion to W=2", " - x86/boot: Use '-std=gnu11' to fix build with GCC 15", " - arm64: dts: qcom: sm8350: Fix MPSS memory length", " - crypto: qce - fix priority to be less than ARMv8 CE", " - xfs: Add error handling for xfs_reflink_cancel_cow_range", " - media: ccs: Clean up parsed CCS static data on parse failure", " - iio: light: as73211: fix channel handling in only-color triggered buffer", " - soc: qcom: smem_state: fix missing of_node_put in error path", " - media: mc: fix endpoint iteration", " - media: ov5640: fix get_light_freq on auto", " - media: ccs: Fix CCS static data parsing for large block sizes", " - media: ccs: Fix cleanup order in ccs_probe()", " - media: uvcvideo: Fix event flags in uvc_ctrl_send_events", " - media: uvcvideo: Remove redundant NULL assignment", " - crypto: qce - fix goto jump in error path", " - crypto: qce - unregister previously registered algos in error path", " - nvmem: qcom-spmi-sdam: Set size in struct nvmem_config", " - nvmem: core: improve range check for nvmem_cell_write()", " - vfio/platform: check the bounds of read/write syscalls", " - pnfs/flexfiles: retry getting layout segment for reads", " - ocfs2: fix incorrect CPU endianness conversion causing mount failure", " - mtd: onenand: Fix uninitialized retlen in do_otp_read()", " - misc: fastrpc: Fix registered buffer page address", " - net/ncsi: wait for the last response to Deselect Package before configuring", " channel", " - net: phy: c45-tjaxx: add delay between MDIO write and read in soft_reset", " - MIPS: ftrace: Declare ftrace_get_parent_ra_addr() as static", " - net/ncsi: use dev_set_mac_address() for Get MC MAC Address handling", " - gpio: xilinx: remove excess kernel doc", " - memory: tegra20-emc: Correct memory device mask", " - ocfs2: check dir i_size in ocfs2_find_entry", " - mptcp: prevent excessive coalescing on receive", " - ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu()", " - drm/i915/selftests: avoid using uninitialized context", " - gpio: bcm-kona: Fix GPIO lock/unlock for banks above bank 0", " - gpio: bcm-kona: Make sure GPIO bits are unlocked when requesting IRQ", " - gpio: bcm-kona: Add missing newline to dev_err format string", " - xen: remove a confusing comment on auto-translated guest I/O", " - x86/xen: allow larger contiguous memory regions in PV guests", " - media: cxd2841er: fix 64-bit division on gcc-9", " - PCI/DPC: Quirk PIO log size for Intel Raptor Lake-P", " - vfio/pci: Enable iowrite64 and ioread64 for vfio pci", " - Grab mm lock before grabbing pt lock", " - x86/mm/tlb: Only trim the mm_cpumask once a second", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet 5V", " - batman-adv: Ignore neighbor throughput metrics in error case", " - perf/x86/intel: Ensure LBRs are disabled when a CPU is starting", " - usb: roles: set switch registered flag early on", " - usb: gadget: udc: renesas_usb3: Fix compiler warning", " - usb: dwc2: gadget: remove of_node reference upon udc_stop", " - USB: pci-quirks: Fix HCCPARAMS register error for LS7A EHCI", " - usb: core: fix pipe creation for get_bMaxPacketSize0", " - USB: quirks: add USB_QUIRK_NO_LPM quirk for Teclast dist", " - USB: Add USB_QUIRK_NO_LPM quirk for sony xperia xz1 smartphone", " - USB: cdc-acm: Fill in Renesas R-Car D3 USB Download mode quirk", " - usb: cdc-acm: Fix handling of oversized fragments", " - USB: serial: option: add MeiG Smart SLM828", " - USB: serial: option: add Telit Cinterion FN990B compositions", " - USB: serial: option: fix Telit Cinterion FN990A name", " - USB: serial: option: drop MeiG Smart defines", " - can: c_can: fix unbalanced runtime PM disable in error path", " - can: j1939: j1939_sk_send_loop(): fix unable to send messages with data", " length zero", " - alpha: make stack 16-byte aligned (most cases)", " - efi: Avoid cold plugged memory for placing the kernel", " - cgroup: fix race between fork and cgroup.kill", " - serial: 8250: Fix fifo underflow on flush", " - alpha: align stack for page fault and user unaligned trap handlers", " - gpio: stmpe: Check return value of stmpe_reg_read in", " stmpe_gpio_irq_sync_unlock", " - regmap-irq: Add missing kfree()", " - arm64: Handle .ARM.attributes section in linker scripts", " - mlxsw: Add return value check for mlxsw_sp_port_get_stats_raw()", " - btrfs: fix hole expansion when writing at an offset beyond EOF", " - clocksource: Replace cpumask_weight() with cpumask_empty()", " - clocksource: Use pr_info() for \"Checking clocksource synchronization\"", " message", " - ipv4: add RCU protection to ip4_dst_hoplimit()", " - net: treat possible_net_t net pointer as an RCU one and add read_pnet_rcu()", " - net: add dev_net_rcu() helper", " - ipv4: use RCU protection in rt_is_expired()", " - ipv4: use RCU protection in inet_select_addr()", " - Namespaceify min_pmtu sysctl", " - Namespaceify mtu_expires sysctl", " - selftest: net: Test IPv4 PMTU exceptions with DSCP and ECN", " - net: ipv4: Cache pmtu for all packet paths if multipath enabled", " - neighbour: delete redundant judgment statements", " - drm/tidss: Fix issue in irq handling causing irq-flood issue", " - drm/tidss: Clear the interrupt status for interrupts being disabled", " - kdb: Do not assume write() callback available", " - alpha: replace hardcoded stack offsets with autogenerated ones", " - nilfs2: do not output warnings when clearing dirty buffers", " - can: ems_pci: move ASIX AX99100 ids to pci_ids.h", " - serial: 8250_pci: add support for ASIX AX99100", " - parport_pc: add support for ASIX AX99100", " - netdevsim: print human readable IP address", " - selftests: rtnetlink: update netdevsim ipsec output format", " - ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus", " - x86/i8253: Disable PIT timer 0 when not in use", " - Revert \"btrfs: avoid monopolizing a core when activating a swap file\"", " - btrfs: avoid monopolizing a core when activating a swap file", " - arm64: mte: Do not allow PROT_MTE on MAP_HUGETLB user mappings", " - crypto: testmgr - fix wrong key length for pkcs1pad", " - crypto: testmgr - Fix wrong test case of RSA", " - crypto: testmgr - fix version number of RSA tests", " - crypto: testmgr - populate RSA CRT parameters in RSA test vectors", " - crypto: testmgr - some more fixes to RSA test vectors", " - mm: update mark_victim tracepoints fields", " - drm/probe-helper: Create a HPD IRQ event helper for a single connector", " - drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()", " - ASoC: renesas: rz-ssi: Add a check for negative sample_space", " - arm64: dts: mediatek: mt8183: Disable DSI display output by default", " - tpm: Use managed allocation for bios event log", " - kfence: allow use of a deferrable timer", " - [Config] updateconfigs to disable new KFENCE_DEFERRABLE", " - kfence: enable check kfence canary on panic via boot param", " - kfence: skip __GFP_THISNODE allocations on NUMA systems", " - soc: mediatek: mtk-devapc: Switch to devm_clk_get_enabled()", " - soc: mediatek: mtk-devapc: Fix leaking IO map on error paths", " - soc/mediatek: mtk-devapc: Convert to platform remove callback returning void", " - soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove", " - media: uvcvideo: Set error_idx during ctrl_commit errors", " - media: uvcvideo: Refactor iterators", " - media: uvcvideo: Only save async fh if success", " - batman-adv: Drop initialization of flexible ethtool_link_ksettings", " - usb: dwc3: Increase DWC3 controller halt timeout", " - usb: dwc3: Fix timeout issue during controller enter/exit from halt state", " - powerpc/64s/mm: Move __real_pte stubs into hash-4k.h", " - powerpc/64s: Rewrite __real_pte() and __rpte_to_hidx() as static inline", " - ALSA: hda/realtek: Fixup ALC225 depop procedure", " - geneve: Suppress list corruption splat in geneve_destroy_tunnels().", " - net: extract port range fields from fl_flow_key", " - flow_dissector: Fix handling of mixed port and port-range keys", " - flow_dissector: Fix port range key handling in BPF conversion", " - net: Add non-RCU dev_getbyhwaddr() helper", " - arp: switch to dev_getbyhwaddr() in arp_req_set_public()", " - power: supply: da9150-fg: fix potential overflow", " - nvme/ioctl: add missing space in err message", " - bpf: skip non exist keys in generic_map_lookup_batch", " - ALSA: hda/conexant: Add quirk for HP ProBook 450 G4 mute LED", " - acct: block access to kernel internal filesystems", " - mtd: rawnand: cadence: fix error code in cadence_nand_init()", " - mtd: rawnand: cadence: use dma_map_resource for sdma address", " - mtd: rawnand: cadence: fix incorrect device in dma_unmap_single", " - x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit", " - IB/mlx5: Set and get correct qp_num for a DCT QP", " - ovl: use wrappers to all vfs_*xattr() calls", " - ovl: pass ofs to creation operations", " - scsi: core: Don't memset() the entire scsi_cmnd in scsi_init_command()", " - scsi: core: Clear driver private data when retrying request", " - RDMA/mlx5: Fix bind QP error cleanup flow", " - sunrpc: suppress warnings for unused procfs functions", " - ALSA: usb-audio: Avoid dropping MIDI events at closing multiple ports", " - Bluetooth: L2CAP: Fix L2CAP_ECRED_CONN_RSP response", " - afs: remove variable nr_servers", " - afs: Make it possible to find the volumes that are using a server", " - afs: Fix the server_list to unuse a displaced server rather than putting it", " - net: loopback: Avoid sending IP packets without an Ethernet header", " - net: cadence: macb: Synchronize stats calculations", " - ASoC: es8328: fix route from DAC to output", " - ipvs: Always clear ipvs_property flag in skb_scrub_packet()", " - tcp: Defer ts_recent changes until req is owned", " - net: mvpp2: cls: Fixed Non IP flow, with vlan tag flow defination.", " - net/mlx5: IRQ, Fix null string in debug print", " - seg6: add support for SRv6 H.Encaps.Red behavior", " - seg6: add support for SRv6 H.L2Encaps.Red behavior", " - include: net: add static inline dst_dev_overhead() to dst.h", " - net: ipv6: seg6_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in seg6 lwt", " - net: ipv6: rpl_iptunnel: mitigate 2-realloc issue", " - net: ipv6: fix dst ref loop on input in rpl lwt", " - x86/CPU: Fix warm boot hang regression on AMD SC1100 SoC systems", " - ftrace: Avoid potential division by zero in function_stat_show()", " - ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2", " - perf/core: Fix low freq setting via IOC_PERIOD", " - drm/amd/display: Fix HPD after gpu reset", " - net: enetc: fix the off-by-one issue in enetc_map_tx_buffs()", " - net: enetc: update UDP checksum when updating originTimestamp field", " - net: enetc: correct the xdp_tx statistics", " - phy: tegra: xusb: reset VBUS & ID OVERRIDE", " - phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk", " - vmlinux.lds: Ensure that const vars with relocations are mapped R/O", " - intel_idle: Handle older CPUs, which stop the TSC in deeper C states,", " correctly", " - drm/amdgpu: Check extended configuration space register when system uses", " large bar", " - drm/amdgpu: disable BAR resize on Dell G5 SE", " - Revert \"of: reserved-memory: Fix using wrong number of cells to get property", " 'alignment'\"", " - HID: appleir: Fix potential NULL dereference at raw event handle", " - gpio: rcar: Use raw_spinlock to protect register access", " - gpio: aggregator: protect driver attr handlers against module unload", " - ALSA: hda: intel: Add Dell ALC3271 to power_save denylist", " - ALSA: hda/realtek: update ALC222 depop optimize", " - drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress 200M", " - platform/x86: thinkpad_acpi: Add battery quirk for ThinkPad X131e", " - x86/cacheinfo: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Validate CPUID leaf 0x2 EDX output", " - x86/cpu: Properly parse CPUID leaf 0x2 TLB descriptor 0x63", " - wifi: cfg80211: regulatory: improve invalid hints checking", " - wifi: nl80211: reject cooked mode if it is set along with other flags", " - rapidio: add check for rio_add_net() in rio_scan_alloc_net()", " - rapidio: fix an API misues when rio_add_net() fails", " - s390/traps: Fix test_monitor_call() inline assembly", " - block: fix conversion of GPT partition name to 7-bit", " - mm/page_alloc: fix uninitialized variable", " - mm: don't skip arch_sync_kernel_mappings() in error paths", " - wifi: iwlwifi: limit printed string from FW file", " - HID: google: fix unused variable warning under !CONFIG_ACPI", " - HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()", " - nvmet-tcp: Fix a possible sporadic response drops in weakly ordered arch", " - net: gso: fix ownership in __udp_gso_segment", " - caif_virtio: fix wrong pointer check in cfv_probe()", " - hwmon: (pmbus) Initialise page count in pmbus_identify()", " - hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor table", " - hwmon: (ad7314) Validate leading zero bits and return error", " - ALSA: usx2y: validate nrpacks module parameter on probe", " - llc: do not use skb_get() before dev_queue_xmit()", " - hwmon: fix a NULL vs IS_ERR_OR_NULL() check in xgene_hwmon_probe()", " - drm/sched: Fix preprocessor guard", " - be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink", " - net: hns3: make sure ptp clock is unregister and freed if", " hclge_ptp_get_cycle returns an error", " - ppp: Fix KMSAN uninit-value warning with bpf", " - vlan: enforce underlying device type", " - x86/sgx: Support loading enclave page without VMA permissions check", " - x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes()", " - x86/sgx: Export sgx_encl_{grow,shrink}()", " - x86/sgx: Support VA page allocation without reclaiming", " - x86/sgx: Fix size overflows in sgx_encl_create()", " - exfat: fix soft lockup in exfat_clear_bitmap", " - net-timestamp: support TCP GSO case for a few missing flags", " - sched/fair: Fix potential memory corruption in child_cfs_rq_on_list", " - net: ipv6: fix dst ref loop in ila lwtunnel", " - net: ipv6: fix missing dst ref drop in ila lwtunnel", " - gpio: rcar: Fix missing of_node_put() call", " - Revert \"drivers/card_reader/rtsx_usb: Restore interrupt based detection\"", " - usb: renesas_usbhs: Call clk_put()", " - usb: renesas_usbhs: Use devm_usb_get_phy()", " - usb: hub: lack of clearing xHC resources", " - usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass Storage Card Reader", " - usb: renesas_usbhs: Flush the notify_hotplug_work", " - usb: atm: cxacru: fix a flaw in existing endpoint checks", " - usb: dwc3: Set SUSPENDENABLE soon after phy init", " - usb: dwc3: gadget: Prevent irq storm when TH re-executes", " - usb: typec: ucsi: increase timeout for PPM reset operations", " - usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix functionality", " - usb: gadget: Set self-powered based on MaxPower and bmAttributes", " - usb: gadget: Fix setting self-powered state on suspend", " - usb: gadget: Check bmAttributes only if configuration is valid", " - xhci: pci: Fix indentation in the PCI device ID definitions", " - usb: xhci: Enable the TRB overfetch quirk on VIA VL805", " - mei: me: add panther lake P DID", " - intel_th: pci: Add Arrow Lake support", " - intel_th: pci: Add Panther Lake-H support", " - intel_th: pci: Add Panther Lake-P/U support", " - slimbus: messaging: Free transaction ID in delayed interrupt scenario", " - bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock", " - eeprom: digsy_mtc: Make GPIO lookup table match the device", " - drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl", " - media: uvcvideo: Avoid invalid memory access", " - media: uvcvideo: Avoid returning invalid controls", " - md: select BLOCK_LEGACY_AUTOLOAD", " - [Config] updateconfigs to select BLOCK_LEGACY_AUTOLOAD", " - mtd: rawnand: cadence: fix unchecked dereference", " - spi-mxs: Fix chipselect glitch", " - nilfs2: move page release outside of nilfs_delete_entry and nilfs_set_link", " - nilfs2: eliminate staggered calls to kunmap in nilfs_rename", " - bpf, vsock: Invoke proto::close on close()", " - kbuild: userprogs: use correct lld when linking through clang", " - net: ipv6: fix dst refleaks in rpl, seg6 and ioam6 lwtunnels", " - Linux 5.15.179", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21647", " - sched: sch_cake: add bounds checks to host bulk flow fairness counts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58002", " - media: uvcvideo: Remove dangling pointers", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58079", " - media: uvcvideo: Fix crash during unbind if gpio unit is in use", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21721", " - nilfs2: handle errors that nilfs_prepare_chunk() may return", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-26982", " - Squashfs: check the inode number is not the invalid value of zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21844", " - smb: client: Add check for next_buffer in receive_encrypted_standard()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58090", " - sched/core: Prevent rescheduling when interrupts are disabled", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21875", " - mptcp: always handle address removal under msk socket lock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21877", " - usbnet: gl620a: fix endpoint checking in genelink_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21878", " - i2c: npcm: disable interrupt enable bit before devm_request_irq", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21887", " - ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21846", " - acct: perform last write from workqueue", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21848", " - nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21862", " - drop_monitor: fix incorrect initialization order", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21871", " - tee: optee: Fix supplicant wait loop", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21865", " - gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21858", " - geneve: Fix use-after-free in geneve_find_dev().", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21866", " - powerpc/code-patching: Fix KASAN hit by not flagging text patching area as", " VM_ALLOC", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21859", " - USB: gadget: f_midi: f_midi_complete to call queue_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21823", " - batman-adv: Drop unmanaged ELP metric worker", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58005", " - tpm: Change to kvalloc() in eventlog/acpi.c", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21748", " - ksmbd: fix integer overflows on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57977", " - memcg: fix soft lockup in the OOM process", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57978", " - media: imx-jpeg: Fix potential error pointer dereference in detach_pm()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57979", " - pps: Fix a use-after-free", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21811", " - nilfs2: protect access to buffers with no active references", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21722", " - nilfs2: do not force clear folio if buffer is referenced", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58086", " - drm/v3d: Stop active perfmon if it is being destroyed", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21758", " - ipv6: mcast: add RCU protection to mld_newpack()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21760", " - ndisc: extend RCU protection in ndisc_send_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21761", " - openvswitch: use RCU protection in ovs_vport_cmd_fill_info()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21762", " - arp: use RCU protection in arp_xmit()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21763", " - neighbour: use RCU protection in __neigh_notify()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21764", " - ndisc: use RCU protection in ndisc_alloc_skb()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21765", " - ipv6: use RCU protection in ip6_default_advmss()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21766", " - ipv4: use RCU protection in __ip_rt_update_pmtu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21767", " - clocksource: Use migrate_disable() to avoid calling get_random_u32() in", " atomic context", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21772", " - partitions: mac: fix handling of bogus partition table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21704", " - usb: cdc-acm: Check control transfer buffer size before access", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21776", " - USB: hub: Ignore non-compliant devices with too many configs or interfaces", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21835", " - usb: gadget: f_midi: fix MIDI Streaming descriptor lengths", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21779", " - KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21781", " - batman-adv: fix panic during interface removal", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21782", " - orangefs: fix a oob in orangefs_debug_write", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57834", " - media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21785", " - arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21787", " - team: better TEAM_OPTION_TYPE_STRING validation", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21791", " - vrf: use RCU protection in l3mdev_l3_out()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58020", " - HID: multitouch: Add NULL check in mt_input_configured", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21795", " - NFSD: fix hang in nfsd4_shutdown_callback", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21796", " - nfsd: clear acl_access/acl_default after releasing them", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21820", " - tty: xilinx_uartps: split sysrq handling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21814", " - ptp: Ensure info->enable callback is always set", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21735", " - NFC: nci: Add bounds checking in nci_hci_create_pipe()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21736", " - nilfs2: fix possible int overflows in nilfs_fiemap()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58001", " - ocfs2: handle a symlink read error correctly", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58007", " - soc: qcom: socinfo: Avoid out of bounds read of serial number", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21744", " - wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21745", " - blk-cgroup: Fix class @block_class's subsystem refcount leakage", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58076", " - clk: qcom: gcc-sm6350: Add missing parent_map for two clocks", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58083", " - KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58010", " - binfmt_flat: Fix integer overflow bug on 32 bit systems", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21749", " - net: rose: lock the socket in rose_bind()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57981", " - usb: xhci: Fix NULL pointer dereference on certain command aborts", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21684", " - gpio: xilinx: Convert gpio_lock to raw spinlock", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58085", " - tomoyo: don't emit warning in tomoyo_write_control()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58014", " - wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58016", " - safesetid: check size of policy writes", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58017", " - printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21753", " - btrfs: fix use-after-free when attempting to join an aborted transaction", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58055", " - usb: gadget: f_tcm: Don't free command immediately", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57980", " - media: uvcvideo: Fix double free in error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21707", " - mptcp: consolidate suboption status", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21708", " - net: usb: rtl8150: enable basic endpoint checking", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21826", " - netfilter: nf_tables: reject mismatching sum of field_len with set key", " length", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21715", " - net: davicom: fix UAF in dm9000_drv_remove", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21718", " - net: rose: fix timer races against user threads", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21719", " - ipmr: do not call mr_mfc_uses_dev() for unres entries", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21802", " - net: hns3: fix oops when unload drivers paralleling", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58058", " - ubifs: skip dumping tnc tree when zroot is null", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58069", " - rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21804", " - PCI: rcar-ep: Fix incorrect variable used when calling", " devm_request_mem_region()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58034", " - memory: tegra20-emc: fix an OF node reference bug in", " tegra_emc_find_node_by_ram_code()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57973", " - rdma/cxgb4: Prevent potential integer overflow on 32bit", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21726", " - padata: avoid UAF for reorder_work", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21727", " - padata: fix UAF in padata_reorder", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21728", " - bpf: Send signals asynchronously if !preemptible", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21711", " - net/rose: prevent integer overflows in rose_setsockopt()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21799", " - net: ethernet: ti: am65-cpsw: fix freeing IRQ in", " am65_cpsw_nuss_remove_tx_chns()", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21806", " - net: let net.core.dev_weight always be non-zero", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21830", " - landlock: Handle weird files", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58071", " - team: prevent adding a device which is already a team device lower", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58063", " - wifi: rtlwifi: fix memory leaks and invalid access at probe error path", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58072", " - wifi: rtlwifi: remove unused check_buddy_priv", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58051", " - ipmi: ipmb: Add check devm_kasprintf() returned value", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-58052", " - drm/amdgpu: Fix potential NULL pointer dereference in", " atomctrl_get_smc_sclk_range_table", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2024-57986", " - HID: core: Fix assumption that Resolution Multipliers must be in Logical", " Collections", " * Jammy update: v5.15.179 upstream stable release (LP: #2106026) //", " CVE-2025-21731", " - nbd: don't allow reconnect after disconnect", " * Fix bugs preventing boot on Intel TDX-enabled hosts (LP: #2097811)", " - x86/mtrr: Remove physical address size calculation", " * Build failure when CONFIG_NET_SWITCHDEV=n due to CVE-2024-26837 fix backport", " (LP: #2104380)", " - SAUCE: net: switchdev: fix compilation error for CONFIG_NET_SWITCHDEV=n", " * nfsd hangs and never recovers after NFS4ERR_DELAY and a connection loss", " (LP: #2103564)", " - NFSD: Reset cb_seq_status after NFS4ERR_DELAY", " * kernel hard lockup in cgroups during eBPF workload (LP: #2089318)", " - cgroup: cgroup: Honor caller's cgroup NS when resolving cgroup id", " - cgroup: Homogenize cgroup_get_from_id() return value", " - cgroup: Make cgroup_get_from_id() prettier", " - cgroup.c: add helper __cset_cgroup_from_root to cleanup duplicated codes", " - cgroup: Reorganize css_set_lock and kernfs path processing", " * CVE-2023-52664", " - net: atlantic: eliminate double free in error handling logic", " * CVE-2023-52927", " - netfilter: allow exp not to be removed in nf_ct_find_expectation", "" ], "package": "linux-kvm", "version": "5.15.0-1080.85", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2106968, 2106996, 1786013, 2103598, 2104326, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2106026, 2097811, 2104380, 2103564, 2089318 ], "author": "Massimiliano Pellizzer ", "date": "Mon, 28 Apr 2025 09:33:48 +0200" } ], "notes": "linux-modules-5.15.0-1080-kvm version '5.15.0-1080.85' (source package linux-kvm version '5.15.0-1080.85') was added. linux-modules-5.15.0-1080-kvm version '5.15.0-1080.85' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1079-kvm. As such we can use the source package version of the removed package, '5.15.0-1079.84', 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-5.15.0-1079-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": "5.15.0-1079.84" }, "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-5.15.0-1079-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1079.84", "version": "5.15.0-1079.84" }, "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-kvm-headers-5.15.0-1079", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": "5.15.0-1079.84" }, "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-5.15.0-1079-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1079.84", "version": "5.15.0-1079.84" }, "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 22.04 jammy image from daily image serial 20250514 to 20250515", "from_series": "jammy", "to_series": "jammy", "from_serial": "20250514", "to_serial": "20250515", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }