Instruction: Please provide detailed information about CVE-2025-21908

CVE:CVE-2025-21908
Description:In the Linux kernel, the following vulnerability has been resolved:  NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback  Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.  Otherwise NFS can deadlock waiting for kcompactd enduced writeback which recurses back to NFS (which triggers writeback to NFSD via NFS loopback mount on the same host, NFSD blocks waiting for XFS's call to __filemap_get_folio):  6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.  {--- [58] "kcompactd0" [<0>] folio_wait_bit+0xe8/0x200 [<0>] folio_wait_writeback+0x2b/0x80 [<0>] nfs_wb_folio+0x80/0x1b0 [nfs] [<0>] nfs_release_folio+0x68/0x130 [nfs] [<0>] split_huge_page_to_list_to_order+0x362/0x840 [<0>] migrate_pages_batch+0x43d/0xb90 [<0>] migrate_pages_sync+0x9a/0x240 [<0>] migrate_pages+0x93c/0x9f0 [<0>] compact_zone+0x8e2/0x1030 [<0>] compact_node+0xdb/0x120 [<0>] kcompactd+0x121/0x2e0 [<0>] kthread+0xcf/0x100 [<0>] ret_from_fork+0x31/0x40 [<0>] ret_from_fork_asm+0x1a/0x30 ---}  [akpm@linux-foundation.org: fix build]
published:2025-04-01T16:15:21.323


Instruction: Please provide detailed information about CVE-2025-21909

CVE:CVE-2025-21909
Description:In the Linux kernel, the following vulnerability has been resolved:  wifi: nl80211: reject cooked mode if it is set along with other flags  It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE flags simultaneously on the same monitor interface from the userspace. This causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit set because the monitor interface is in the cooked state and it takes precedence over all other states. When the interface is then being deleted the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing that bit.  Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with other flags.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
published:2025-04-01T16:15:21.430


Instruction: Please provide detailed information about CVE-2025-21910

CVE:CVE-2025-21910
Description:In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: regulatory: improve invalid hints checking  Syzbot keeps reporting an issue [1] that occurs when erroneous symbols sent from userspace get through into user_alpha2[] via regulatory_hint_user() call. Such invalid regulatory hints should be rejected.  While a sanity check from commit 47caf685a685 ("cfg80211: regulatory: reject invalid hints") looks to be enough to deter these very cases, there is a way to get around it due to 2 reasons.  1) The way isalpha() works, symbols other than latin lower and upper letters may be used to determine a country/domain. For instance, greek letters will also be considered upper/lower letters and for such characters isalpha() will return true as well. However, ISO-3166-1 alpha2 codes should only hold latin characters.  2) While processing a user regulatory request, between reg_process_hint_user() and regulatory_hint_user() there happens to be a call to queue_regulatory_request() which modifies letters in request->alpha2[] with toupper(). This works fine for latin symbols, less so for weird letter characters from the second part of _ctype[].  Syzbot triggers a warning in is_user_regdom_saved() by first sending over an unexpected non-latin letter that gets malformed by toupper() into a character that ends up failing isalpha() check.  Prevent this by enhancing is_an_alpha2() to ensure that incoming symbols are latin letters and nothing else.  [1] Syzbot report: ------------[ cut here ]------------ Unexpected user alpha2: A� WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 Modules linked in: CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_power_efficient crda_timeout_work RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline] RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline] RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 ... Call Trace:  <TASK>  crda_timeout_work+0x27/0x50 net/wireless/reg.c:542  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f2/0x390 kernel/kthread.c:389  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  </TASK>
published:2025-04-01T16:15:21.550


Instruction: Please provide detailed information about CVE-2025-21911

CVE:CVE-2025-21911
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/imagination: avoid deadlock on fence release  Do scheduler queue fence release processing on a workqueue, rather than in the release function itself.  Fixes deadlock issues such as the following:  [  607.400437] ============================================ [  607.405755] WARNING: possible recursive locking detected [  607.415500] -------------------------------------------- [  607.420817] weston:zfq0/24149 is trying to acquire lock: [  607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [  607.436728]                but task is already holding lock: [  607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554 [  607.451727]                other info that might help us debug this: [  607.458245]  Possible unsafe locking scenario:  [  607.464155]        CPU0 [  607.466601]        ---- [  607.469044]   lock(reservation_ww_class_mutex); [  607.473584]   lock(reservation_ww_class_mutex); [  607.478114]                 *** DEADLOCK ***
published:2025-04-01T16:15:21.677


Instruction: Please provide detailed information about CVE-2025-21912

CVE:CVE-2025-21912
Description:In the Linux kernel, the following vulnerability has been resolved:  gpio: rcar: Use raw_spinlock to protect register access  Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access.      [    4.239592] =============================     [    4.239595] [ BUG: Invalid wait context ]     [    4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted     [    4.239603] -----------------------------     [    4.239606] kworker/u8:5/76 is trying to lock:     [    4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164     [    4.239641] other info that might help us debug this:     [    4.239643] context-{5:5}     [    4.239646] 5 locks held by kworker/u8:5/76:     [    4.239651]  #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c     [    4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.     [    4.254094]  #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c     [    4.254109]  #2: ffff00000920c8f8     [    4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.     [    4.264803]  (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc     [    4.264820]  #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690     [    4.264840]  #4:     [    4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.     [    4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690     [    4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz     [    4.304082] stack backtrace:     [    4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35     [    4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)     [    4.304097] Workqueue: async async_run_entry_fn     [    4.304106] Call trace:     [    4.304110]  show_stack+0x14/0x20 (C)     [    4.304122]  dump_stack_lvl+0x6c/0x90     [    4.304131]  dump_stack+0x14/0x1c     [    4.304138]  __lock_acquire+0xdfc/0x1584     [    4.426274]  lock_acquire+0x1c4/0x33c     [    4.429942]  _raw_spin_lock_irqsave+0x5c/0x80     [    4.434307]  gpio_rcar_config_interrupt_input_mode+0x34/0x164     [    4.440061]  gpio_rcar_irq_set_type+0xd4/0xd8     [    4.444422]  __irq_set_trigger+0x5c/0x178     [    4.448435]  __setup_irq+0x2e4/0x690     [    4.452012]  request_threaded_irq+0xc4/0x190     [    4.456285]  devm_request_threaded_irq+0x7c/0xf4     [    4.459398] ata1: link resume succeeded after 1 retries     [    4.460902]  mmc_gpiod_request_cd_irq+0x68/0xe0     [    4.470660]  mmc_start_host+0x50/0xac     [    4.474327]  mmc_add_host+0x80/0xe4     [    4.477817]  tmio_mmc_host_probe+0x2b0/0x440     [    4.482094]  renesas_sdhi_probe+0x488/0x6f4     [    4.486281]  renesas_sdhi_internal_dmac_probe+0x60/0x78     [    4.491509]  platform_probe+0x64/0xd8     [    4.495178]  really_probe+0xb8/0x2a8     [    4.498756]  __driver_probe_device+0x74/0x118     [    4.503116]  driver_probe_device+0x3c/0x154     [    4.507303]  __device_attach_driver+0xd4/0x160     [    4.511750]  bus_for_each_drv+0x84/0xe0     [    4.515588]  __device_attach_async_helper+0xb0/0xdc     [    4.520470]  async_run_entry_fn+0x30/0xd8     [    4.524481]  process_one_work+0x210/0x62c     [    4.528494]  worker_thread+0x1ac/0x340     [    4.532245]  kthread+0x10c/0x110     [    4.535476]  ret_from_fork+0x10/0x20
published:2025-04-01T16:15:21.780


Instruction: Please provide detailed information about CVE-2025-21913

CVE:CVE-2025-21913
Description:In the Linux kernel, the following vulnerability has been resolved:  x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()  Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests.  This results in the following warning:    unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)   Call Trace:    xen_read_msr+0x1e/0x30    amd_get_mmconfig_range+0x2b/0x80    quirk_amd_mmconfig_area+0x28/0x100    pnp_fixup_device+0x39/0x50    __pnp_add_device+0xf/0x150    pnp_add_device+0x3d/0x100    pnpacpi_add_device_handler+0x1f9/0x280    acpi_ns_get_device_callback+0x104/0x1c0    acpi_ns_walk_namespace+0x1d0/0x260    acpi_get_devices+0x8a/0xb0    pnpacpi_init+0x50/0x80    do_one_initcall+0x46/0x2e0    kernel_init_freeable+0x1da/0x2f0    kernel_init+0x16/0x1b0    ret_from_fork+0x30/0x50    ret_from_fork_asm+0x1b/0x30  based on quirks for a "PNP0c01" device.  Treating MMCFG as disabled is the right course of action, so no change is needed there.  This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.
published:2025-04-01T16:15:21.893


Instruction: Please provide detailed information about CVE-2025-21914

CVE:CVE-2025-21914
Description:In the Linux kernel, the following vulnerability has been resolved:  slimbus: messaging: Free transaction ID in delayed interrupt scenario  In case of interrupt delay for any reason, slim_do_transfer() returns timeout error but the transaction ID (TID) is not freed. This results into invalid memory access inside qcom_slim_ngd_rx_msgq_cb() due to invalid TID.  Fix the issue by freeing the TID in slim_do_transfer() before returning timeout error to avoid invalid memory access.  Call trace: __memcpy_fromio+0x20/0x190 qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl] vchan_complete+0x2a0/0x4a0 tasklet_action_common+0x274/0x700 tasklet_action+0x28/0x3c _stext+0x188/0x620 run_ksoftirqd+0x34/0x74 smpboot_thread_fn+0x1d8/0x464 kthread+0x178/0x238 ret_from_fork+0x10/0x20 Code: aa0003e8 91000429 f100044a 3940002b (3800150b) ---[ end trace 0fe00bec2b975c99 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt.
published:2025-04-01T16:15:21.997


Instruction: Please provide detailed information about CVE-2025-21915

CVE:CVE-2025-21915
Description:In the Linux kernel, the following vulnerability has been resolved:  cdx: Fix possible UAF error in driver_override_show()  Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c  This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs.  The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users.  Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues.  This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations.
published:2025-04-01T16:15:22.117


Instruction: Please provide detailed information about CVE-2025-21916

CVE:CVE-2025-21916
Description:In the Linux kernel, the following vulnerability has been resolved:  usb: atm: cxacru: fix a flaw in existing endpoint checks  Syzbot once again identified a flaw in usb endpoint checking, see [1]. This time the issue stems from a commit authored by me (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).  While using usb_find_common_endpoints() may usually be enough to discard devices with wrong endpoints, in this case one needs more than just finding and identifying the sufficient number of endpoints of correct types - one needs to check the endpoint's address as well.  Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind, switch the endpoint verification approach to usb_check_XXX_endpoints() instead to fix incomplete ep testing.  [1] Syzbot report: usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace:  <TASK>  cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649  cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline]  cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223  usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058  cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377  usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396  really_probe+0x2b9/0xad0 drivers/base/dd.c:658  __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800  driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ...
published:2025-04-01T16:15:22.223


Instruction: Please provide detailed information about CVE-2025-21917

CVE:CVE-2025-21917
Description:In the Linux kernel, the following vulnerability has been resolved:  usb: renesas_usbhs: Flush the notify_hotplug_work  When performing continuous unbind/bind operations on the USB drivers available on the Renesas RZ/G2L SoC, a kernel crash with the message "Unable to handle kernel NULL pointer dereference at virtual address" may occur. This issue points to the usbhsc_notify_hotplug() function.  Flush the delayed work to avoid its execution when driver resources are unavailable.
published:2025-04-01T16:15:22.350


Instruction: Please provide detailed information about CVE-2025-21918

CVE:CVE-2025-21918
Description:In the Linux kernel, the following vulnerability has been resolved:  usb: typec: ucsi: Fix NULL pointer access  Resources should be released only after all threads that utilize them have been destroyed. This commit ensures that resources are not released prematurely by waiting for the associated workqueue to complete before deallocating them.
published:2025-04-01T16:15:22.457


Instruction: Please provide detailed information about CVE-2025-21919

CVE:CVE-2025-21919
Description:In the Linux kernel, the following vulnerability has been resolved:  sched/fair: Fix potential memory corruption in child_cfs_rq_on_list  child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq. This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list, making the conversion invalid and potentially leading to memory corruption. Depending on the relative positions of leaf_cfs_rq_list and the task group (tg) pointer within the struct, this can cause a memory fault or access garbage data.  The issue arises in list_add_leaf_cfs_rq, where both cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.  This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main conditional in child_cfs_rq_on_list. This ensures that the container_of operation will convert a correct cfs_rq struct.  This check is sufficient because only cfs_rqs on the same CPU are added to the list, so verifying the 'prev' pointer against the current rq's list head is enough.  Fixes a potential memory corruption issue that due to current struct layout might not be manifesting as a crash but could lead to unpredictable behavior when the layout changes.
published:2025-04-01T16:15:22.557


Instruction: Please provide detailed information about CVE-2025-21920

CVE:CVE-2025-21920
Description:In the Linux kernel, the following vulnerability has been resolved:  vlan: enforce underlying device type  Currently, VLAN devices can be created on top of non-ethernet devices.  Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode.  When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device.  As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add.  __dev_mc_add uses dev->addr_len to determine the length of the new multicast address.  This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.  This behaviour can be reproduced using the following commands:  ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100  Then, the following command will display the address of garp_pdu_rcv:  ip maddr show | grep 01:80:c2:00:00:21  Fix the bug by enforcing the type of the underlying device during VLAN device initialization.
published:2025-04-01T16:15:22.673


Instruction: Please provide detailed information about CVE-2025-21921

CVE:CVE-2025-21921
Description:In the Linux kernel, the following vulnerability has been resolved:  net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device  ethnl_req_get_phydev() is used to lookup a phy_device, in the case an ethtool netlink command targets a specific phydev within a netdev's topology.  It takes as a parameter a const struct nlattr *header that's used for error handling :         if (!phydev) {                NL_SET_ERR_MSG_ATTR(extack, header,                                    "no phy matching phyindex");                return ERR_PTR(-ENODEV);        }  In the notify path after a ->set operation however, there's no request attributes available.  The typical callsite for the above function looks like:  	phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER], 				      info->extack);  So, when tb is NULL (such as in the ethnl notify path), we have a nice crash.  It turns out that there's only the PLCA command that is in that case, as the other phydev-specific commands don't have a notification.  This commit fixes the crash by passing the cmd index and the nlattr array separately, allowing NULL-checking it directly inside the helper.
published:2025-04-01T16:15:22.790


Instruction: Please provide detailed information about CVE-2025-21922

CVE:CVE-2025-21922
Description:In the Linux kernel, the following vulnerability has been resolved:  ppp: Fix KMSAN uninit-value warning with bpf  Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.  The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.  As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.  The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.  For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.  [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000
published:2025-04-01T16:15:22.893


Instruction: Please provide detailed information about CVE-2025-21923

CVE:CVE-2025-21923
Description:In the Linux kernel, the following vulnerability has been resolved:  HID: hid-steam: Fix use-after-free when detaching device  When a hid-steam device is removed it must clean up the client_hdev used for intercepting hidraw access. This can lead to scheduling deferred work to reattach the input device. Though the cleanup cancels the deferred work, this was done before the client_hdev itself is cleaned up, so it gets rescheduled. This patch fixes the ordering to make sure the deferred work is properly canceled.
published:2025-04-01T16:15:23.007


Instruction: Please provide detailed information about CVE-2025-21924

CVE:CVE-2025-21924
Description:In the Linux kernel, the following vulnerability has been resolved:  net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an error  During the initialization of ptp, hclge_ptp_get_cycle might return an error and returned directly without unregister clock and free it. To avoid that, call hclge_ptp_destroy_clock to unregist and free clock if hclge_ptp_get_cycle failed.
published:2025-04-01T16:15:23.110


Instruction: Please provide detailed information about CVE-2025-21925

CVE:CVE-2025-21925
Description:In the Linux kernel, the following vulnerability has been resolved:  llc: do not use skb_get() before dev_queue_xmit()  syzbot is able to crash hosts [1], using llc and devices not supporting IFF_TX_SKB_SHARING.  In this case, e1000 driver calls eth_skb_pad(), while the skb is shared.  Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c  Note that e1000 driver might have an issue with pktgen, because it does not clear IFF_TX_SKB_SHARING, this is an orthogonal change.  We need to audit other skb_get() uses in net/llc.  [1]  kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014  RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace:  <TASK>   __skb_pad+0x18a/0x610 net/core/skbuff.c:2466   __skb_put_padto include/linux/skbuff.h:3843 [inline]   skb_put_padto include/linux/skbuff.h:3862 [inline]   eth_skb_pad include/linux/etherdevice.h:656 [inline]   e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128   __netdev_start_xmit include/linux/netdevice.h:5151 [inline]   netdev_start_xmit include/linux/netdevice.h:5160 [inline]   xmit_one net/core/dev.c:3806 [inline]   dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822   sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343   __dev_xmit_skb net/core/dev.c:4045 [inline]   __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621   dev_queue_xmit include/linux/netdevice.h:3313 [inline]   llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144   llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]   llc_sap_next_state net/llc/llc_sap.c:182 [inline]   llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209   llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993   sock_sendmsg_nosec net/socket.c:718 [inline]
published:2025-04-01T16:15:23.227


Instruction: Please provide detailed information about CVE-2025-21926

CVE:CVE-2025-21926
Description:In the Linux kernel, the following vulnerability has been resolved:  net: gso: fix ownership in __udp_gso_segment  In __udp_gso_segment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug:    kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)   RIP: 0010:ip_rcv_core+0x8b2/0xca0   Call Trace:    ip_rcv+0xab/0x6e0    __netif_receive_skb_one_core+0x168/0x1b0    process_backlog+0x384/0x1100    __napi_poll.constprop.0+0xa1/0x370    net_rx_action+0x925/0xe50  The above can happen following a sequence of events when using OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an OVS_ACTION_ATTR_OUTPUT action:  1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb    goes through queue_gso_packets and then __udp_gso_segment, where its    destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the    same original skb is sent to its path. 4. If it later hits skb_orphan, we hit the bug.  Fix this by also removing the reference to the socket in __udp_gso_segment.
published:2025-04-01T16:15:23.350


Instruction: Please provide detailed information about CVE-2025-21927

CVE:CVE-2025-21927
Description:In the Linux kernel, the following vulnerability has been resolved:  nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()  nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.  Fix this by rejecting packets with an unexpected header length.
published:2025-04-01T16:15:23.470


Instruction: Please provide detailed information about CVE-2025-21928

CVE:CVE-2025-21928
Description:In the Linux kernel, the following vulnerability has been resolved:  HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()  The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function.  The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory.  This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed.
published:2025-04-01T16:15:23.613


Instruction: Please provide detailed information about CVE-2025-21929

CVE:CVE-2025-21929
Description:In the Linux kernel, the following vulnerability has been resolved:  HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove()  During the `rmmod` operation for the `intel_ishtp_hid` driver, a use-after-free issue can occur in the hid_ishtp_cl_remove() function. The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(), which can lead to accessing freed memory or resources during the removal process.  Call Trace:  ? ishtp_cl_send+0x168/0x220 [intel_ishtp]  ? hid_output_report+0xe3/0x150 [hid]  hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid]  ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid]  hid_hw_request+0x1f/0x40 [hid]  sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub]  _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger]  hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger]  sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub]  hid_device_remove+0x49/0xb0 [hid]  hid_destroy_device+0x6f/0x90 [hid]  ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid]  hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid]  ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp]  ...  Additionally, ishtp_hid_remove() is a HID level power off, which should occur before the ISHTP level disconnect.  This patch resolves the issue by reordering the calls in hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now called before hid_ishtp_cl_deinit().
published:2025-04-01T16:15:23.740


Instruction: Please provide detailed information about CVE-2025-21930

CVE:CVE-2025-21930
Description:In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: don't try to talk to a dead firmware  This fixes:   bad state = 0  WARNING: CPU: 10 PID: 702 at drivers/net/wireless/inel/iwlwifi/iwl-trans.c:178 iwl_trans_send_cmd+0xba/0xe0 [iwlwifi]  Call Trace:   <TASK>   ? __warn+0xca/0x1c0   ? iwl_trans_send_cmd+0xba/0xe0 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]   iwl_fw_dbg_clear_monitor_buf+0xd7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]   _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea92d2c341766bcc10b18699290068a]  Ask whether the firmware is alive before sending a command.
published:2025-04-01T16:15:23.837


Instruction: Please provide detailed information about CVE-2025-21931

CVE:CVE-2025-21931
Description:In the Linux kernel, the following vulnerability has been resolved:  hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio  Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page.  However folio lock must be held before calling try_to_unmap.  Add it to fix this problem.  Warning will be produced if folio is not locked during unmap:    ------------[ cut here ]------------   kernel BUG at ./include/linux/swapops.h:400!   Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP   Modules linked in:   CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G        W          6.13.0-rc1-00016-g3c434c7ee82a-dirty #41   Tainted: [W]=WARN   Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015   pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)   pc : try_to_unmap_one+0xb08/0xd3c   lr : try_to_unmap_one+0x3dc/0xd3c   Call trace:    try_to_unmap_one+0xb08/0xd3c (P)    try_to_unmap_one+0x3dc/0xd3c (L)    rmap_walk_anon+0xdc/0x1f8    rmap_walk+0x3c/0x58    try_to_unmap+0x88/0x90    unmap_poisoned_folio+0x30/0xa8    do_migrate_range+0x4a0/0x568    offline_pages+0x5a4/0x670    memory_block_action+0x17c/0x374    memory_subsys_offline+0x3c/0x78    device_offline+0xa4/0xd0    state_store+0x8c/0xf0    dev_attr_store+0x18/0x2c    sysfs_kf_write+0x44/0x54    kernfs_fop_write_iter+0x118/0x1a8    vfs_write+0x3a8/0x4bc    ksys_write+0x6c/0xf8    __arm64_sys_write+0x1c/0x28    invoke_syscall+0x44/0x100    el0_svc_common.constprop.0+0x40/0xe0    do_el0_svc+0x1c/0x28    el0_svc+0x30/0xd0    el0t_64_sync_handler+0xc8/0xcc    el0t_64_sync+0x198/0x19c   Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)   ---[ end trace 0000000000000000 ]---
published:2025-04-01T16:15:23.933


Instruction: Please provide detailed information about CVE-2025-21932

CVE:CVE-2025-21932
Description:In the Linux kernel, the following vulnerability has been resolved:  mm: abort vma_modify() on merge out of memory failure  The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt.  Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue.  This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values.  Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e.  the kernel would simply keep retrying reclaim until it succeeded.  However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it.  The safest option is, when this scenario occurs, to simply give up the operation.  If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!).  Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early.  So there is no doubt it is appropriate to simply bail out in this scenario.  However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields.  As a result, additionally also make this clear by storing start, end in local variables.  The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert:  	VM_WARN_ON_VMG(start >= end, vmg);  In vma_merge_existing_range().  It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this:          start     end           |<------>|      |----------|------|      |   vma    | next |      |----------|------|  When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop.  We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value:  		/* Here vma->vm_start <= start < (end|vma->vm_end) */ 		tmp = vma->vm_end;  We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation:  		/* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ 		error = visit(vma, &prev, start, tmp, arg);  Where the visit() function pointer in this instance is madvise_vma_behavior().  As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn.  Then, in vma_modify(), we attempt the merge:  	merged = vma_merge_existing_range(vmg); 	if (merged) 		return merged;  We invoke this with vmg->start, end set to start, tmp as such:          start  tmp           |<--->|      |----------|------|      |   vma    | next |      |----------|------|  We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma).  Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next.  This means vmg->start, end are set to...  vma->vm_start, start.  Now the commit_merge() fails, and vmg->start, end are left like this.  This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as:    start' end'      |<-->|      |----------|------|      |   vma    | next |      |----------|------|  So we now erroneously try to split accordingly.  This is where the unfortunate ---truncated---
published:2025-04-01T16:15:24.040


Instruction: Please provide detailed information about CVE-2025-21933

CVE:CVE-2025-21933
Description:In the Linux kernel, the following vulnerability has been resolved:  arm: pgtable: fix NULL pointer dereference issue  When update_mmu_cache_range() is called by update_mmu_cache(), the vmf parameter is NULL, which will cause a NULL pointer dereference issue in adjust_pte():  Unable to handle kernel NULL pointer dereference at virtual address 00000030 when read Hardware name: Atmel AT91SAM9 PC is at update_mmu_cache_range+0x1e0/0x278 LR is at pte_offset_map_rw_nolock+0x18/0x2c Call trace:  update_mmu_cache_range from remove_migration_pte+0x29c/0x2ec  remove_migration_pte from rmap_walk_file+0xcc/0x130  rmap_walk_file from remove_migration_ptes+0x90/0xa4  remove_migration_ptes from migrate_pages_batch+0x6d4/0x858  migrate_pages_batch from migrate_pages+0x188/0x488  migrate_pages from compact_zone+0x56c/0x954  compact_zone from compact_node+0x90/0xf0  compact_node from kcompactd+0x1d4/0x204  kcompactd from kthread+0x120/0x12c  kthread from ret_from_fork+0x14/0x38 Exception stack(0xc0d8bfb0 to 0xc0d8bff8)  To fix it, do not rely on whether 'ptl' is equal to decide whether to hold the pte lock, but decide it by whether CONFIG_SPLIT_PTE_PTLOCKS is enabled.  In addition, if two vmas map to the same PTE page, there is no need to hold the pte lock again, otherwise a deadlock will occur.  Just add the need_lock parameter to let adjust_pte() know this information.
published:2025-04-01T16:15:24.143


Instruction: Please provide detailed information about CVE-2025-21934

CVE:CVE-2025-21934
Description:In the Linux kernel, the following vulnerability has been resolved:  rapidio: fix an API misues when rio_add_net() fails  rio_add_net() calls device_register() and fails when device_register() fails.  Thus, put_device() should be used rather than kfree().  Add "mport->net = NULL;" to avoid a use after free issue.
published:2025-04-01T16:15:24.243


Instruction: Please provide detailed information about CVE-2025-21935

CVE:CVE-2025-21935
Description:In the Linux kernel, the following vulnerability has been resolved:  rapidio: add check for rio_add_net() in rio_scan_alloc_net()  The return value of rio_add_net() should be checked.  If it fails, put_device() should be called to free the memory and give up the reference initialized in rio_add_net().
published:2025-04-01T16:15:24.353


Instruction: Please provide detailed information about CVE-2025-21936

CVE:CVE-2025-21936
Description:In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()  Add check for the return value of mgmt_alloc_skb() in mgmt_device_connected() to prevent null pointer dereference.
published:2025-04-01T16:15:24.467


Instruction: Please provide detailed information about CVE-2025-21937

CVE:CVE-2025-21937
Description:In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()  Add check for the return value of mgmt_alloc_skb() in mgmt_remote_name() to prevent null pointer dereference.
published:2025-04-01T16:15:24.560


Instruction: Please provide detailed information about CVE-2025-21938

CVE:CVE-2025-21938
Description:In the Linux kernel, the following vulnerability has been resolved:  mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr  If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id.  In this case, the concurrent new_local_addr calls may delete the address entry created by the previous caller.  These deletes use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.  During packet recv, the caller may be in a rcu read critical section and have preemption disabled.  An example stack:     BUG: scheduling while atomic: swapper/2/0/0x00000302     Call Trace:    <IRQ>    dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))    dump_stack (lib/dump_stack.c:124)    __schedule_bug (kernel/sched/core.c:5943)    schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)    __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)    schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)    schedule_timeout (kernel/time/timer.c:2160)    wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)    __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)    synchronize_rcu (kernel/rcu/tree.c:3609)    mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)    mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)    mptcp_pm_get_local_id (net/mptcp/pm.c:420)    subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)    subflow_v4_route_req (net/mptcp/subflow.c:305)    tcp_conn_request (net/ipv4/tcp_input.c:7216)    subflow_v4_conn_request (net/mptcp/subflow.c:651)    tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)    tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)    tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)    ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))    ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)    ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)    ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)    ip_sublist_rcv (net/ipv4/ip_input.c:640)    ip_list_rcv (net/ipv4/ip_input.c:675)    __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)    netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)    napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)    igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb    __napi_poll (net/core/dev.c:6582)    net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)    handle_softirqs (kernel/softirq.c:553)    __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)    irq_exit_rcu (kernel/softirq.c:651)    common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))    </IRQ>  This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address.  In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first local_addr_list entries which have the internal address instead.  Fix by skipping the replacement of an existing implicit local address if called via mptcp_pm_nl_get_local_id.
published:2025-04-01T16:15:24.667


Instruction: Please provide detailed information about CVE-2025-21939

CVE:CVE-2025-21939
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/xe/hmm: Don't dereference struct page pointers without notifier lock  The pnfs that we obtain from hmm_range_fault() point to pages that we don't have a reference on, and the guarantee that they are still in the cpu page-tables is that the notifier lock must be held and the notifier seqno is still valid.  So while building the sg table and marking the pages accesses / dirty we need to hold this lock with a validated seqno.  However, the lock is reclaim tainted which makes sg_alloc_table_from_pages_segment() unusable, since it internally allocates memory.  Instead build the sg-table manually. For the non-iommu case this might lead to fewer coalesces, but if that's a problem it can be fixed up later in the resource cursor code. For the iommu case, the whole sg-table may still be coalesced to a single contigous device va region.  This avoids marking pages that we don't own dirty and accessed, and it also avoid dereferencing struct pages that we don't own.  v2: - Use assert to check whether hmm pfns are valid (Matthew Auld) - Take into account that large pages may cross range boundaries   (Matthew Auld)  v3: - Don't unnecessarily check for a non-freed sg-table. (Matthew Auld) - Add a missing up_read() in an error path. (Matthew Auld)  (cherry picked from commit ea3e66d280ce2576664a862693d1da8fd324c317)
published:2025-04-01T16:15:24.773


Instruction: Please provide detailed information about CVE-2025-21940

CVE:CVE-2025-21940
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix NULL Pointer Dereference in KFD queue  Through KFD IOCTL Fuzzing we encountered a NULL pointer derefrence when calling kfd_queue_acquire_buffers.  (cherry picked from commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530)
published:2025-04-01T16:15:24.873


Instruction: Please provide detailed information about CVE-2025-21941

CVE:CVE-2025-21941
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params  Null pointer dereference issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not null before accessing. This prevents a null pointer dereference.  Found by code review.  (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
published:2025-04-01T16:15:24.983


Instruction: Please provide detailed information about CVE-2025-21942

CVE:CVE-2025-21942
Description:In the Linux kernel, the following vulnerability has been resolved:  btrfs: zoned: fix extent range end unlock in cow_file_range()  Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent.    INFO: task kworker/u128:1:12 blocked for more than 323 seconds.         Not tainted 6.13.0-BTRFS-ZNS+ #503   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.   task:kworker/u128:1  state:D stack:0     pid:12    tgid:12    ppid:2      flags:0x00004000   Workqueue: btrfs-fixup btrfs_work_helper [btrfs]   Call Trace:    <TASK>    __schedule+0x534/0xdd0    schedule+0x39/0x140    __lock_extent+0x31b/0x380 [btrfs]    ? __pfx_autoremove_wake_function+0x10/0x10    btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]    btrfs_work_helper+0xff/0x480 [btrfs]    ? lock_release+0x178/0x2c0    process_one_work+0x1ee/0x570    ? srso_return_thunk+0x5/0x5f    worker_thread+0x1d1/0x3b0    ? __pfx_worker_thread+0x10/0x10    kthread+0x10b/0x230    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x30/0x50    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>   INFO: task kworker/u134:0:184 blocked for more than 323 seconds.         Not tainted 6.13.0-BTRFS-ZNS+ #503   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.   task:kworker/u134:0  state:D stack:0     pid:184   tgid:184   ppid:2      flags:0x00004000   Workqueue: writeback wb_workfn (flush-btrfs-4)   Call Trace:    <TASK>    __schedule+0x534/0xdd0    schedule+0x39/0x140    __lock_extent+0x31b/0x380 [btrfs]    ? __pfx_autoremove_wake_function+0x10/0x10    find_lock_delalloc_range+0xdb/0x260 [btrfs]    writepage_delalloc+0x12f/0x500 [btrfs]    ? srso_return_thunk+0x5/0x5f    extent_write_cache_pages+0x232/0x840 [btrfs]    btrfs_writepages+0x72/0x130 [btrfs]    do_writepages+0xe7/0x260    ? srso_return_thunk+0x5/0x5f    ? lock_acquire+0xd2/0x300    ? srso_return_thunk+0x5/0x5f    ? find_held_lock+0x2b/0x80    ? wbc_attach_and_unlock_inode.part.0+0x102/0x250    ? wbc_attach_and_unlock_inode.part.0+0x102/0x250    __writeback_single_inode+0x5c/0x4b0    writeback_sb_inodes+0x22d/0x550    __writeback_inodes_wb+0x4c/0xe0    wb_writeback+0x2f6/0x3f0    wb_workfn+0x32a/0x510    process_one_work+0x1ee/0x570    ? srso_return_thunk+0x5/0x5f    worker_thread+0x1d1/0x3b0    ? __pfx_worker_thread+0x10/0x10    kthread+0x10b/0x230    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x30/0x50    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>  This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions.  (1) If the given range is never allocated, we can only wait for someone     to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry     afterward.  (2) Or, if some allocations are already done, we must bail out and let     the caller to send IOs for the allocation. This is because these IOs     may be necessary to finish a zone.  The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue.  Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case.
published:2025-04-01T16:15:25.100


Instruction: Please provide detailed information about CVE-2025-21943

CVE:CVE-2025-21943
Description:In the Linux kernel, the following vulnerability has been resolved:  gpio: aggregator: protect driver attr handlers against module unload  Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held.  Add try_module_get() in these handlers.  For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:    #!/bin/bash   while :; do     # note: whether 'gpiochip0 0' exists or not does not matter.     echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device   done &   while :; do     modprobe gpio-aggregator     modprobe -r gpio-aggregator   done &   wait    Starting with the following warning, several kinds of warnings will appear   and the system may become unstable:    ------------[ cut here ]------------   list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100)   WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120   [...]   RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120   [...]   Call Trace:    <TASK>    ? __list_del_entry_valid_or_report+0xa3/0x120    ? __warn.cold+0x93/0xf2    ? __list_del_entry_valid_or_report+0xa3/0x120    ? report_bug+0xe6/0x170    ? __irq_work_queue_local+0x39/0xe0    ? handle_bug+0x58/0x90    ? exc_invalid_op+0x13/0x60    ? asm_exc_invalid_op+0x16/0x20    ? __list_del_entry_valid_or_report+0xa3/0x120    gpiod_remove_lookup_table+0x22/0x60    new_device_store+0x315/0x350 [gpio_aggregator]    kernfs_fop_write_iter+0x137/0x1f0    vfs_write+0x262/0x430    ksys_write+0x60/0xd0    do_syscall_64+0x6c/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e    [...]    </TASK>   ---[ end trace 0000000000000000 ]---
published:2025-04-01T16:15:25.400


Instruction: Please provide detailed information about CVE-2025-21944

CVE:CVE-2025-21944
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix bug on trap in smb2_lock  If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.
published:2025-04-01T16:15:25.513


Instruction: Please provide detailed information about CVE-2025-21945

CVE:CVE-2025-21945
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in smb2_lock  If smb_lock->zero_len has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine.
published:2025-04-01T16:15:25.633


Instruction: Please provide detailed information about CVE-2025-21946

CVE:CVE-2025-21946
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix out-of-bounds in parse_sec_desc()  If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size.
published:2025-04-01T16:15:25.730


Instruction: Please provide detailed information about CVE-2025-21947

CVE:CVE-2025-21947
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix type confusion via race condition when using ipc_msg_send_request  req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.
published:2025-04-01T16:15:25.830


Instruction: Please provide detailed information about CVE-2025-21948

CVE:CVE-2025-21948
Description:In the Linux kernel, the following vulnerability has been resolved:  HID: appleir: Fix potential NULL dereference at raw event handle  Syzkaller reports a NULL pointer dereference issue in input_event().  BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline] BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395 Read of size 8 at addr 0000000000000028 by task syz-executor199/2949  CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace:  <IRQ>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120  kasan_report+0xd9/0x110 mm/kasan/report.c:602  check_region_inline mm/kasan/generic.c:183 [inline]  kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189  instrument_atomic_read include/linux/instrumented.h:68 [inline]  _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]  is_event_supported drivers/input/input.c:67 [inline]  input_event+0x42/0xa0 drivers/input/input.c:395  input_report_key include/linux/input.h:439 [inline]  key_down drivers/hid/hid-appleir.c:159 [inline]  appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232  __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111  hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484  __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650  usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734  dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993  __run_hrtimer kernel/time/hrtimer.c:1739 [inline]  __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803  hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820  handle_softirqs+0x206/0x8d0 kernel/softirq.c:561  __do_softirq kernel/softirq.c:595 [inline]  invoke_softirq kernel/softirq.c:435 [inline]  __irq_exit_rcu+0xfa/0x160 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+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049  </IRQ>  <TASK>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702  __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185  add_timer+0x62/0x90 kernel/time/timer.c:1295  schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98  usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645  usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784  hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:906 [inline]  __se_sys_ioctl fs/ioctl.c:892 [inline]  __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892  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  </TASK>  This happens due to the malformed report items sent by the emulated device which results in a report, that has no fields, being added to the report list. Due to this appleir_input_configured() is never called, hidinput_connect() fails which results in the HID_CLAIMED_INPUT flag is not being set. However, it  does not make appleir_probe() fail and lets the event callback to be called without the associated input device.  Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook early if the driver didn't claim any input_dev for some reason. Moreover, some other hid drivers accessing input_dev in their event callbacks do have similar checks, too.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
published:2025-04-01T16:15:25.933


Instruction: Please provide detailed information about CVE-2025-21949


Instruction: Please provide detailed information about CVE-2025-21950

CVE:CVE-2025-21950
Description:In the Linux kernel, the following vulnerability has been resolved:  drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl  In the "pmcmd_ioctl" function, three memory objects allocated by kmalloc are initialized by "hcall_get_cpu_state", which are then copied to user space. The initializer is indeed implemented in "acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of information leakage due to uninitialized bytes.
published:2025-04-01T16:15:26.180


Instruction: Please provide detailed information about CVE-2025-21951

CVE:CVE-2025-21951
Description:In the Linux kernel, the following vulnerability has been resolved:  bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock  There are multiple places from where the recovery work gets scheduled asynchronously. Also, there are multiple places where the caller waits synchronously for the recovery to be completed. One such place is during the PM shutdown() callback.  If the device is not alive during recovery_work, it will try to reset the device using pci_reset_function(). This function internally will take the device_lock() first before resetting the device. By this time, if the lock has already been acquired, then recovery_work will get stalled while waiting for the lock. And if the lock was already acquired by the caller which waits for the recovery_work to be completed, it will lead to deadlock.  This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver's shutdown() callback while holding the device_lock() leading to deadlock.  And this deadlock scenario can occur on other paths as well, like during the PM suspend() callback, where the driver core would hold the device_lock() before calling driver's suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.  So to fix both issues, use pci_try_reset_function() in recovery_work. This function first checks for the availability of the device_lock() before trying to reset the device. If the lock is available, it will acquire it and reset the device. Otherwise, it will return -EAGAIN. If that happens, recovery_work will fail with the error message "Recovery failed" as not much could be done.
published:2025-04-01T16:15:26.297


Instruction: Please provide detailed information about CVE-2025-21952

CVE:CVE-2025-21952
Description:In the Linux kernel, the following vulnerability has been resolved:  HID: corsair-void: Update power supply values with a unified work handler  corsair_void_process_receiver can be called from an interrupt context, locking battery_mutex in it was causing a kernel panic. Fix it by moving the critical section into its own work, sharing this work with battery_add_work and battery_remove_work to remove the need for any locking
published:2025-04-01T16:15:26.413


Instruction: Please provide detailed information about CVE-2025-21953

CVE:CVE-2025-21953
Description:In the Linux kernel, the following vulnerability has been resolved:  net: mana: cleanup mana struct after debugfs_remove()  When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(), mana_gd_suspend() and mana_gd_resume() are called. If during this mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs pointer does not get reinitialized and ends up pointing to older, cleaned-up dentry. Further in the hibernation path, as part of power_down(), mana_gd_shutdown() is triggered. This call, unaware of the failures in resume, tries to cleanup the already cleaned up  mana_port_debugfs value and hits the following bug:  [  191.359296] mana 7870:00:00.0: Shutdown was called [  191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098 [  191.360584] #PF: supervisor write access in kernel mode [  191.361125] #PF: error_code(0x0002) - not-present page [  191.361727] PGD 1080ea067 P4D 0 [  191.362172] Oops: Oops: 0002 [#1] SMP NOPTI [  191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2 [  191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [  191.364124] RIP: 0010:down_write+0x19/0x50 [  191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d [  191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246 [  191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000 [  191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098 [  191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001 [  191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000 [  191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020 [  191.369549] FS:  00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000 [  191.370213] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0 [  191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [  191.372906] Call Trace: [  191.373262]  <TASK> [  191.373621]  ? show_regs+0x64/0x70 [  191.374040]  ? __die+0x24/0x70 [  191.374468]  ? page_fault_oops+0x290/0x5b0 [  191.374875]  ? do_user_addr_fault+0x448/0x800 [  191.375357]  ? exc_page_fault+0x7a/0x160 [  191.375971]  ? asm_exc_page_fault+0x27/0x30 [  191.376416]  ? down_write+0x19/0x50 [  191.376832]  ? down_write+0x12/0x50 [  191.377232]  simple_recursive_removal+0x4a/0x2a0 [  191.377679]  ? __pfx_remove_one+0x10/0x10 [  191.378088]  debugfs_remove+0x44/0x70 [  191.378530]  mana_detach+0x17c/0x4f0 [  191.378950]  ? __flush_work+0x1e2/0x3b0 [  191.379362]  ? __cond_resched+0x1a/0x50 [  191.379787]  mana_remove+0xf2/0x1a0 [  191.380193]  mana_gd_shutdown+0x3b/0x70 [  191.380642]  pci_device_shutdown+0x3a/0x80 [  191.381063]  device_shutdown+0x13e/0x230 [  191.381480]  kernel_power_off+0x35/0x80 [  191.381890]  hibernate+0x3c6/0x470 [  191.382312]  state_store+0xcb/0xd0 [  191.382734]  kobj_attr_store+0x12/0x30 [  191.383211]  sysfs_kf_write+0x3e/0x50 [  191.383640]  kernfs_fop_write_iter+0x140/0x1d0 [  191.384106]  vfs_write+0x271/0x440 [  191.384521]  ksys_write+0x72/0xf0 [  191.384924]  __x64_sys_write+0x19/0x20 [  191.385313]  x64_sys_call+0x2b0/0x20b0 [  191.385736]  do_syscall_64+0x79/0x150 [  191.386146]  ? __mod_memcg_lruvec_state+0xe7/0x240 [  191.386676]  ? __lruvec_stat_mod_folio+0x79/0xb0 [  191.387124]  ? __pfx_lru_add+0x10/0x10 [  191.387515]  ? queued_spin_unlock+0x9/0x10 [  191.387937]  ? do_anonymous_page+0x33c/0xa00 [  191.388374]  ? __handle_mm_fault+0xcf3/0x1210 [  191.388805]  ? __count_memcg_events+0xbe/0x180 [  191.389235]  ? handle_mm_fault+0xae/0x300 [  19 ---truncated---
published:2025-04-01T16:15:26.513


Instruction: Please provide detailed information about CVE-2025-21954

CVE:CVE-2025-21954
Description:In the Linux kernel, the following vulnerability has been resolved:  netmem: prevent TX of unreadable skbs  Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it.  Fix this by preventing the xmit of unreadable skbs.  Tested by configuring tc redirect:  sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \ 	tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1  Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs.  After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs.
published:2025-04-01T16:15:26.610


Instruction: Please provide detailed information about CVE-2025-21955

CVE:CVE-2025-21955
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: prevent connection release during oplock break notification  ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.
published:2025-04-01T16:15:26.710


Instruction: Please provide detailed information about CVE-2025-21956

CVE:CVE-2025-21956
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Assign normalized_pix_clk when color depth = 14  [WHY & HOW] A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the display_color_depth == COLOR_DEPTH_141414 is not handled. This is observed in Radeon RX 6600 XT.  It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.  Also fixes the indentation in get_norm_pix_clk.  (cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
published:2025-04-01T16:15:26.810


Instruction: Please provide detailed information about CVE-2025-21957

CVE:CVE-2025-21957
Description:In the Linux kernel, the following vulnerability has been resolved:  scsi: qla1280: Fix kernel oops when debug level > 2  A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2.  I think its clear from the code that the intention here is sg_dma_len(s) not length of sg_next(s) when printing the debug info.
published:2025-04-01T16:15:26.910


Instruction: Please provide detailed information about CVE-2025-21958

CVE:CVE-2025-21958
Description:In the Linux kernel, the following vulnerability has been resolved:  Revert "openvswitch: switch to per-action label counting in conntrack"  Currently, ovs_ct_set_labels() is only called for confirmed conntrack entries (ct) within ovs_ct_commit(). However, if the conntrack entry does not have the labels_ext extension, attempting to allocate it in ovs_ct_get_conn_labels() for a confirmed entry triggers a warning in nf_ct_ext_add():    WARN_ON(nf_ct_is_confirmed(ct));  This happens when the conntrack entry is created externally before OVS increments net->ct.labels_used. The issue has become more likely since commit fcb1aa5163b1 ("openvswitch: switch to per-action label counting in conntrack"), which changed to use per-action label counting and increment net->ct.labels_used when a flow with ct action is added.  Since there’s no straightforward way to fully resolve this issue at the moment, this reverts the commit to avoid breaking existing use cases.
published:2025-04-01T16:15:27.010


Instruction: Please provide detailed information about CVE-2025-21959

CVE:CVE-2025-21959
Description:In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()  Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbage collection confirm race"), `cpu` and `jiffies32` were introduced to the struct nf_conncount_tuple.  The commit made nf_conncount_add() initialize `conn->cpu` and `conn->jiffies32` when allocating the struct. In contrast, count_tree() was not changed to initialize them.  By commit 34848d5c896e ("netfilter: nf_conncount: Split insert and traversal"), count_tree() was split and the relevant allocation code now resides in insert_tree(). Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().  BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline] BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143  find_or_evict net/netfilter/nf_conncount.c:117 [inline]  __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143  count_tree net/netfilter/nf_conncount.c:438 [inline]  nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521  connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72  __nft_match_eval net/netfilter/nft_compat.c:403 [inline]  nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]  nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288  nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626  nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663  NF_HOOK_LIST include/linux/netfilter.h:350 [inline]  ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633  ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669  __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline]  __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983  __netif_receive_skb_list net/core/dev.c:6035 [inline]  netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126  netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178  xdp_recv_frames net/bpf/test_run.c:280 [inline]  xdp_test_run_batch net/bpf/test_run.c:361 [inline]  bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390  bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316  bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407  __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813  __do_sys_bpf kernel/bpf/syscall.c:5902 [inline]  __se_sys_bpf kernel/bpf/syscall.c:5900 [inline]  __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900  ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358  do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]  __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387  do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412  do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450  entry_SYSENTER_compat_after_hwframe+0x84/0x8e  Uninit was created at:  slab_post_alloc_hook mm/slub.c:4121 [inline]  slab_alloc_node mm/slub.c:4164 [inline]  kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171  insert_tree net/netfilter/nf_conncount.c:372 [inline]  count_tree net/netfilter/nf_conncount.c:450 [inline]  nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521  connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72  __nft_match_eval net/netfilter/nft_compat.c:403 [inline]  nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]  nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288  nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626  nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663  NF_HOOK_LIST include/linux/netfilter.h:350 [inline]  ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633  ip_list_rcv+0x9ef/0xa40 net/ip ---truncated---
published:2025-04-01T16:15:27.120


Instruction: Please provide detailed information about CVE-2025-21960

CVE:CVE-2025-21960
Description:In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: do not update checksum in bnxt_xdp_build_skb()  The bnxt_rx_pkt() updates ip_summed value at the end if checksum offload is enabled. When the XDP-MB program is attached and it returns XDP_PASS, the bnxt_xdp_build_skb() is called to update skb_shared_info. The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info, but it updates ip_summed value too if checksum offload is enabled. This is actually duplicate work.  When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed is CHECKSUM_NONE or not. It means that ip_summed should be CHECKSUM_NONE at this moment. But ip_summed may already be updated to CHECKSUM_UNNECESSARY in the XDP-MB-PASS path. So the by skb_checksum_none_assert() WARNS about it.  This is duplicate work and updating ip_summed in the bnxt_xdp_build_skb() is not needed.  Splat looks like: WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en] Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_] CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G        W          6.14.0-rc4+ #27 Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en] Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f RSP: 0018:ffff88881ba09928 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000 RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8 RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070 R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080 R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000 FS:  00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace:  <IRQ>  ? __warn+0xcd/0x2f0  ? bnxt_rx_pkt+0x479b/0x7610  ? report_bug+0x326/0x3c0  ? handle_bug+0x53/0xa0  ? exc_invalid_op+0x14/0x50  ? asm_exc_invalid_op+0x16/0x20  ? bnxt_rx_pkt+0x479b/0x7610  ? bnxt_rx_pkt+0x3e41/0x7610  ? __pfx_bnxt_rx_pkt+0x10/0x10  ? napi_complete_done+0x2cf/0x7d0  __bnxt_poll_work+0x4e8/0x1220  ? __pfx___bnxt_poll_work+0x10/0x10  ? __pfx_mark_lock.part.0+0x10/0x10  bnxt_poll_p5+0x36a/0xfa0  ? __pfx_bnxt_poll_p5+0x10/0x10  __napi_poll.constprop.0+0xa0/0x440  net_rx_action+0x899/0xd00 ...  Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.
published:2025-04-01T16:15:27.230


Instruction: Please provide detailed information about CVE-2025-21961

CVE:CVE-2025-21961
Description:In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: fix truesize for mb-xdp-pass case  When mb-xdp is set and return is XDP_PASS, packet is converted from xdp_buff to sk_buff with xdp_update_skb_shared_info() in bnxt_xdp_build_skb(). bnxt_xdp_build_skb() passes incorrect truesize argument to xdp_update_skb_shared_info(). The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but the skb_shared_info was wiped by napi_build_skb() before. So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it instead of getting skb_shared_info from xdp_get_shared_info_from_buff().  Splat looks like:  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590  Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms  CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3  RIP: 0010:skb_try_coalesce+0x504/0x590  Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99  RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287  RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0  RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003  RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900  R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740  R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002  FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <IRQ>   ? __warn+0x84/0x130   ? skb_try_coalesce+0x504/0x590   ? report_bug+0x18a/0x1a0   ? handle_bug+0x53/0x90   ? exc_invalid_op+0x14/0x70   ? asm_exc_invalid_op+0x16/0x20   ? skb_try_coalesce+0x504/0x590   inet_frag_reasm_finish+0x11f/0x2e0   ip_defrag+0x37a/0x900   ip_local_deliver+0x51/0x120   ip_sublist_rcv_finish+0x64/0x70   ip_sublist_rcv+0x179/0x210   ip_list_rcv+0xf9/0x130  How to reproduce: <Node A> ip link set $interface1 xdp obj xdp_pass.o ip link set $interface1 mtu 9000 up ip a a 10.0.0.1/24 dev $interface1 <Node B> ip link set $interfac2 mtu 9000 up ip a a 10.0.0.2/24 dev $interface2 ping 10.0.0.1 -s 65000  Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.
published:2025-04-01T16:15:27.343


Instruction: Please provide detailed information about CVE-2025-21962

CVE:CVE-2025-21962
Description:In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix integer overflow while processing closetimeo mount option  User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
published:2025-04-01T16:15:27.447


Instruction: Please provide detailed information about CVE-2025-21963

CVE:CVE-2025-21963
Description:In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix integer overflow while processing acdirmax mount option  User-provided mount parameter acdirmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
published:2025-04-01T16:15:27.550


Instruction: Please provide detailed information about CVE-2025-21964

CVE:CVE-2025-21964
Description:In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix integer overflow while processing acregmax mount option  User-provided mount parameter acregmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
published:2025-04-01T16:15:27.657


Instruction: Please provide detailed information about CVE-2025-21965

CVE:CVE-2025-21965
Description:In the Linux kernel, the following vulnerability has been resolved:  sched_ext: Validate prev_cpu in scx_bpf_select_cpu_dfl()  If a BPF scheduler provides an invalid CPU (outside the nr_cpu_ids range) as prev_cpu to scx_bpf_select_cpu_dfl() it can cause a kernel crash.  To prevent this, validate prev_cpu in scx_bpf_select_cpu_dfl() and trigger an scx error if an invalid CPU is specified.
published:2025-04-01T16:15:27.767


Instruction: Please provide detailed information about CVE-2025-21966

CVE:CVE-2025-21966
Description:In the Linux kernel, the following vulnerability has been resolved:  dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature  Fix memory corruption due to incorrect parameter being passed to bio_init
published:2025-04-01T16:15:27.873


Instruction: Please provide detailed information about CVE-2025-21967

CVE:CVE-2025-21967
Description:In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in ksmbd_free_work_struct  ->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.
published:2025-04-01T16:15:27.983


Instruction: Please provide detailed information about CVE-2025-21968

CVE:CVE-2025-21968
Description:In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix slab-use-after-free on hdcp_work  [Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running.  [How] Cancel the delayed work when destroying workqueue.  (cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
published:2025-04-01T16:15:28.090


Instruction: Please provide detailed information about CVE-2025-21969

CVE:CVE-2025-21969
Description:In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd  After the hci sync command releases l2cap_conn, the hci receive data work queue references the released l2cap_conn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two.  [1] BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837  CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci1 hci_rx_work Call Trace:  <TASK>  __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  l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]  l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954  l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]  l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817  hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]  hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  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  </TASK>  Allocated by task 5837:  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]  kzalloc_noprof include/linux/slab.h:1037 [inline]  l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860  l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239  hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]  hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726  hci_event_func net/bluetooth/hci_event.c:7473 [inline]  hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525  hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  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  Freed by task 54:  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  l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235  hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]  hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266  hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603  hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  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/entr ---truncated---
published:2025-04-01T16:15:28.207


Instruction: Please provide detailed information about CVE-2025-21970

CVE:CVE-2025-21970
Description:In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Bridge, fix the crash caused by LAG state check  When removing LAG device from bridge, NETDEV_CHANGEUPPER event is triggered. Driver finds the lower devices (PFs) to flush all the offloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns false if one of PF is unloaded. In such case, mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of the alive PF, and the flush is skipped.  Besides, the bridge fdb entry's lastuse is updated in mlx5 bridge event handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be ignored in this case because the upper interface for bond is deleted, and the entry will never be aged because lastuse is never updated.  To make things worse, as the entry is alive, mlx5 bridge workqueue keeps sending that event, which is then handled by kernel bridge notifier. It causes the following crash when accessing the passed bond netdev which is already destroyed.  To fix this issue, remove such checks. LAG state is already checked in commit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when adding bond to bridge"), driver still need to skip offload if LAG becomes invalid state after initialization.   Oops: stack segment: 0000 [#1] SMP  CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G           OE      6.11.0_mlnx #1  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014  Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core]  RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge]  Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7  RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297  RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff  RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0  RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60  R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000  FS:  0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   <TASK>   ? __die_body+0x1a/0x60   ? die+0x38/0x60   ? do_trap+0x10b/0x120   ? do_error_trap+0x64/0xa0   ? exc_stack_segment+0x33/0x50   ? asm_exc_stack_segment+0x22/0x30   ? br_switchdev_event+0x2c/0x110 [bridge]   ? sched_balance_newidle.isra.149+0x248/0x390   notifier_call_chain+0x4b/0xa0   atomic_notifier_call_chain+0x16/0x20   mlx5_esw_bridge_update+0xec/0x170 [mlx5_core]   mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core]   process_scheduled_works+0x81/0x390   worker_thread+0x106/0x250   ? bh_worker+0x110/0x110   kthread+0xb7/0xe0   ? kthread_park+0x80/0x80   ret_from_fork+0x2d/0x50   ? kthread_park+0x80/0x80   ret_from_fork_asm+0x11/0x20   </TASK>
published:2025-04-01T16:15:28.323


Instruction: Please provide detailed information about CVE-2025-21971

CVE:CVE-2025-21971
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.
published:2025-04-01T16:15:28.440


Instruction: Please provide detailed information about CVE-2025-21972

CVE:CVE-2025-21972
Description:In the Linux kernel, the following vulnerability has been resolved:  net: mctp: unshare packets when reassembling  Ensure that the frag_list used for reassembly isn't shared with other packets. This avoids incorrect reassembly when packets are cloned, and prevents a memory leak due to circular references between fragments and their skb_shared_info.  The upcoming MCTP-over-USB driver uses skb_clone which can trigger the problem - other MCTP drivers don't share SKBs.  A kunit test is added to reproduce the issue.
published:2025-04-01T16:15:28.540


Instruction: Please provide detailed information about CVE-2025-21973

CVE:CVE-2025-21973
Description:In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: fix kernel panic in the bnxt_get_queue_stats{rx | tx}  When qstats-get operation is executed, callbacks of netdev_stats_ops are called. The bnxt_get_queue_stats{rx | tx} collect per-queue stats from sw_stats in the rings. But {rx | tx | cp}_ring are allocated when the interface is up. So, these rings are not allocated when the interface is down.  The qstats-get is allowed even if the interface is down. However, the bnxt_get_queue_stats{rx | tx}() accesses cp_ring and tx_ring without null check. So, it needs to avoid accessing rings if the interface is down.  Reproducer:  ip link set $interface down  ./cli.py --spec netdev.yaml --dump qstats-get OR  ip link set $interface down  python ./stats.py  Splat looks like:  BUG: kernel NULL pointer dereference, address: 0000000000000000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 0 UID: 0 PID: 1495 Comm: python3 Not tainted 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341  Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021  RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en]  Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01  RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282  RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000  RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000  RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c  R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000  R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000  FS:  00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <TASK>   ? __die+0x20/0x70   ? page_fault_oops+0x15a/0x460   ? sched_balance_find_src_group+0x58d/0xd10   ? exc_page_fault+0x6e/0x180   ? asm_exc_page_fault+0x22/0x30   ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1]   netdev_nl_stats_by_netdev+0x2b1/0x4e0   ? xas_load+0x9/0xb0   ? xas_find+0x183/0x1d0   ? xa_find+0x8b/0xe0   netdev_nl_qstats_get_dumpit+0xbf/0x1e0   genl_dumpit+0x31/0x90   netlink_dump+0x1a8/0x360
published:2025-04-01T16:15:28.637


Instruction: Please provide detailed information about CVE-2025-21974

CVE:CVE-2025-21974
Description:In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc()  The bnxt_queue_mem_alloc() is called to allocate new queue memory when a queue is restarted. It internally accesses rx buffer descriptor corresponding to the index. The rx buffer descriptor is allocated and set when the interface is up and it's freed when the interface is down. So, if queue is restarted if interface is down, kernel panic occurs.  Splat looks like:  BUG: unable to handle page fault for address: 000000000000b240  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 Not tainted 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e  Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021  RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en]  Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15  RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202  RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000  RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808  RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000  R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f  R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000  FS:  00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <TASK>   ? __die+0x20/0x70   ? page_fault_oops+0x15a/0x460   ? exc_page_fault+0x6e/0x180   ? asm_exc_page_fault+0x22/0x30   ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]   ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]   netdev_rx_queue_restart+0xc5/0x240   net_devmem_bind_dmabuf_to_queue+0xf8/0x200   netdev_nl_bind_rx_doit+0x3a7/0x450   genl_family_rcv_msg_doit+0xd9/0x130   genl_rcv_msg+0x184/0x2b0   ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10   ? __pfx_genl_rcv_msg+0x10/0x10   netlink_rcv_skb+0x54/0x100   genl_rcv+0x24/0x40 ...
published:2025-04-01T16:15:28.737


Instruction: Please provide detailed information about CVE-2025-21975

CVE:CVE-2025-21975
Description:In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: handle errors in mlx5_chains_create_table()  In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns() and mlx5_get_flow_namespace() must be checked to prevent NULL pointer dereferences. If either function fails, the function should log error message with mlx5_core_warn() and return error pointer.
published:2025-04-01T16:15:28.853


Instruction: Please provide detailed information about CVE-2025-21976

CVE:CVE-2025-21976
Description:In the Linux kernel, the following vulnerability has been resolved:  fbdev: hyperv_fb: Allow graceful removal of framebuffer  When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released.  [   44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [   44.111289] Call Trace: [   44.111290]  <TASK> [   44.111291]  ? show_regs+0x6c/0x80 [   44.111295]  ? __warn+0x8d/0x150 [   44.111298]  ? framebuffer_release+0x2c/0x40 [   44.111300]  ? report_bug+0x182/0x1b0 [   44.111303]  ? handle_bug+0x6e/0xb0 [   44.111306]  ? exc_invalid_op+0x18/0x80 [   44.111308]  ? asm_exc_invalid_op+0x1b/0x20 [   44.111311]  ? framebuffer_release+0x2c/0x40 [   44.111313]  ? hvfb_remove+0x86/0xa0 [hyperv_fb] [   44.111315]  vmbus_remove+0x24/0x40 [hv_vmbus] [   44.111323]  device_remove+0x40/0x80 [   44.111325]  device_release_driver_internal+0x20b/0x270 [   44.111327]  ? bus_find_device+0xb3/0xf0  Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully.  While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer.
published:2025-04-01T16:15:28.973