HuttenlocherTechnologies
Updated 10 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,769exploited flaws on CISA’s list
30added in the last 30 days
459new WordPress flaws this week
394,717entries in the database

18,763 results · page 244 of 376

  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57aCVE-2025-37889 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() Add NULL check for mlx5_gCVE-2025-37888 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() Add NULL check for mlx5_get_flow_namespace() returns in mlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent NULL pointer dereference.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the CVE-2025-37887 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

    In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_infoCVE-2025-37886 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back toCVE-2025-37885 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

    In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex.CVE-2025-37884 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_paCVE-2025-37883 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix isochronous Ring Underrun/Overrun event handling The TRB pointer of these eCVE-2025-37882 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix isochronous Ring Underrun/Overrun event handling The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position. I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC. Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all. Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, rCVE-2025-37881 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: um: work around sched_yield not yielding in time-travel mode sched_yield by a userspace maCVE-2025-37880 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: um: work around sched_yield not yielding in time-travel mode sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Work around it by accounting time to the process whenever it executes a sched_yield syscall.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() anCVE-2025-37879 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

    In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctxCVE-2025-37878 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routin

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: iommu: Clear iommu-dma ops on cleanup If iommu_device_register() encounters an error, it cCVE-2025-37877 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: iommu: Clear iommu-dma ops on cleanup If iommu_device_register() encounters an error, it can end up tearing down already-configured groups and default domains, however this currently still leaves devices hooked up to iommu-dma (and even historically the behaviour in this area was at best inconsistent across architectures/drivers...) Although in the case that an IOMMU is present whose driver has failed to probe, users cannot necessarily expect DMA to work anyway, it's still arguable that we should do our best to put things back as if the IOMMU driver was never there at all, and certainly the potential for crashing in iommu-dma itself is undesirable. Make sure we clean up the dev->dma_iommu flag along with everything else.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS When testing a special config: CONFCVE-2025-37876 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7

    In the Linux kernel, the following vulnerability has been resolved: netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS When testing a special config: CONFIG_NETFS_SUPPORTS=y CONFIG_PROC_FS=n The system crashes with something like: [ 3.766197] ------------[ cut here ]------------ [ 3.766484] kernel BUG at mm/mempool.c:560! [ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W [ 3.767777] Tainted: [W]=WARN [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19 [ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00 [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286 [ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000 [ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff [ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828 [ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0 [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40 [ 3.772554] FS: 000000000

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTMCVE-2025-37875 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memorCVE-2025-37874 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent error paths after ngbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix missing ring index trim on error path Commit under Fixes converted tx_prod CVE-2025-37873 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix missing ring index trim on error path Commit under Fixes converted tx_prod to be free running but missed masking it on the Tx error path. This crashes on error conditions, for example when DMA mapping fails.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, meCVE-2025-37872 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent error paths after txgbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init().

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: nfsd: decrease sc_count directly if fail to queue dl_recall A deadlock warning occurred whCVE-2025-37871 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

    In the Linux kernel, the following vulnerability has been resolved: nfsd: decrease sc_count directly if fail to queue dl_recall A deadlock warning occurred when invoking nfs4_put_stid following a failed dl_recall queue operation: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers __break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lock When a file is opened, an nfs4_delegation is allocated with sc_count initialized to 1, and the file_lease holds a reference to the delegation. The file_lease is then associated with the file through kernel_setlease. The disassociation is performed in nfsd4_delegreturn via the following call chain: nfsd4_delegreturn --> destroy_delegation --> dest

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: prevent hang on link training fail [Why] When link training fails, the phCVE-2025-37870 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: prevent hang on link training fail [Why] When link training fails, the phy clock will be disabled. However, in enable_streams, it is assumed that link training succeeded and the mux selects the phy clock, causing a hang when a register write is made. [How] When enable_stream is hit, check if link training failed. If it did, fall back to the ref clock to avoid a hang and keep the system in a recoverable state.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in CVE-2025-37869 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/xe/userptr: fix notifier vs folio deadlock User is reporting what smells like notifierCVE-2025-37868 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/xe/userptr: fix notifier vs folio deadlock User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock. Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it. (cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Silence oversized kvmalloc() warning syzkaller triggered an oversized kvmalloc(CVE-2025-37867 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Silence oversized kvmalloc() warning syzkaller triggered an oversized kvmalloc() warning. Silence it by adding __GFP_NOWARN. syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show() A warning is seen whenCVE-2025-37866 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show() A warning is seen when running the latest kernel on a BlueField SOC: [251.512704] ------------[ cut here ]------------ [251.512711] invalid sysfs_emit: buf:0000000003aa32ae [251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8 The warning is triggered because the mlxbf-bootctl driver invokes "sysfs_emit()" with a buffer pointer that is not aligned to the start of the page. The driver should instead use "sysfs_emit_at()" to support non-zero offsets into the destination buffer.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King rCVE-2025-37865 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: if (!sid) return 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and i

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as coCVE-2025-37864 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user spac

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: ovl: don't allow datadir only In theory overlayfs could support upper layer directly referCVE-2025-37863 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: ovl: don't allow datadir only In theory overlayfs could support upper layer directly referring to a data layer, but there's no current use case for this. Originally, when data-only layers were introduced, this wasn't allowed, only introduced by the "datadir+" feature, but without actually handling this case, resulting in an Oops. Fix by disallowing datadir without lowerdir.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a nuCVE-2025-37862 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task manCVE-2025-37861 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pCVE-2025-37859 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates alloCVE-2025-37858 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instCVE-2025-37857 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instead of a fixed value.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these caCVE-2025-37856 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref earl

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Guard Possible Null Pointer Dereference [WHY] In some situations, dc->resCVE-2025-37855 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Guard Possible Null Pointer Dereference [WHY] In some situations, dc->res_pool may be null. [HOW] Check if pointer is null before dereference.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to rCVE-2025-37854 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: debugfs hang_hws skip GPU with MES debugfs hang_hws is used by GPU reset test CVE-2025-37853 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: debugfs hang_hws skip GPU with MES debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path. Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error hCVE-2025-37852 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: Add 'plane' value check Function dispc_ovl_setup is not intended to work wiCVE-2025-37851 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: Add 'plane' value check Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() With CONFIG_COMPILE_TEST &&CVE-2025-37850 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config() With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero. This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero. Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to sharCVE-2025-37849 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Tear down vGIC on failed vCPU creation If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix PM related deadlocks in MS IOCTLs Prevent runtime resume/suspend while MS CVE-2025-37848 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix PM related deadlocks in MS IOCTLs Prevent runtime resume/suspend while MS IOCTLs are in progress. Failed suspend will call ivpu_ms_cleanup() that would try to acquire file_priv->ms_lock, which is already held by the IOCTLs.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in ivpu_ms_cleanup() Fix deadlock in ivpu_ms_cleanup() by preventCVE-2025-37847 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in ivpu_ms_cleanup() Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after file_priv->ms_lock is acquired. During a failure in runtime resume, a cold boot is executed, which calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup() that acquires file_priv->ms_lock and causes the deadlock.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: arm64: mops: Do not dereference src reg for a set operation The source register is not useCVE-2025-37846 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

    In the Linux kernel, the following vulnerability has been resolved: arm64: mops: Do not dereference src reg for a set operation The source register is not used for SET* and reading it can result in a UBSAN out-of-bounds array access error, specifically when the MOPS exception is taken from a SET* sequence with XZR (reg 31) as the source. Architecturally this is the only case where a src/dst/size field in the ESR can be reported as 31. Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the use of pt_regs_read_reg() prevented the out-of-bounds access.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: tracing: fprobe events: Fix possible UAF on modules Commit ac91052f0ae5 ("tracing: tprobe-CVE-2025-37845 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: tracing: fprobe events: Fix possible UAF on modules Commit ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module refcount") moved try_module_get() from __find_tracepoint_module_cb() to find_tracepoint() caller, but that introduced a possible UAF because the module can be unloaded before try_module_get(). In this case, the module object should be freed too. Thus, try_module_get() does not only fail but may access to the freed object. To avoid that, try_module_get() in __find_tracepoint_module_cb() again.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: cifs: avoid NULL pointer dereference in dbg call cifs_server_dbg() implies server to be noCVE-2025-37844 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: cifs: avoid NULL pointer dereference in dbg call cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Avoid unnecessary device replacement check Hot-removal of nested PCI hotplug CVE-2025-37843 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Avoid unnecessary device replacement check Hot-removal of nested PCI hotplug ports suffers from a long-standing race condition which can lead to a deadlock: A parent hotplug port acquires pci_lock_rescan_remove(), then waits for pciehp to unbind from a child hotplug port. Meanwhile that child hotplug port tries to acquire pci_lock_rescan_remove() as well in order to remove its own children. The deadlock only occurs if the parent acquires pci_lock_rescan_remove() first, not if the child happens to acquire it first. Several workarounds to avoid the issue have been proposed and discarded over the years, e.g.: https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/ A proper fix is being worked on, but needs more time as it is nontrivial and necessarily intrusive. Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during system sleep") provokes more frequent occurrence of the deadlock when removing more than one Thunderbolt device during system sleep. The commit sought to detect device replacement, but also triggered on device removal. Di

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: spi: fsl-qspi: use devm function instead of driver remove Driver use devm APIs to manage cCVE-2025-37842 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: spi: fsl-qspi: use devm function instead of driver remove Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: pm: cpupower: bench: Prevent NULL dereference on malloc failure If malloc returns NULL dueCVE-2025-37841 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

    In the Linux kernel, the following vulnerability has been resolved: pm: cpupower: bench: Prevent NULL dereference on malloc failure If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caCVE-2025-37840 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • May 9, 2025In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequeCVE-2025-37839 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

    In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.

    Product
    Linux
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Get in touch

Tell us what you're building.

A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.

01The person who'll do the work writes back
02A short call, then a written plan with the price
03Nothing starts until you say yes
04Hacked or down right now? Call, and we pick up the same day
843-331-6339

Not ready to talk yet? Run the free website check and see what Google sees.

What do you need?
Build
Grow
Protect
Urgent

No newsletter, no sales sequence. Just a reply.