Updated 6 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,768exploited flaws on CISA’s list

34added in the last 30 days

279new WordPress flaws this week

393,576entries in the database

22,048 results · page 188 of 441

Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected" This reverts commit c608966f3f9c2dcCVE-2025-40192 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd process ref leaking when userptr unmapping kfd_lookup_process_by_pid hCVE-2025-40191 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd process ref leaking when userptr unmapping kfd_lookup_process_by_pid hold the kfd process reference to ensure it doesn't get destroyed while sending the segfault event to user space. Calling kfd_lookup_process_by_pid as function parameter leaks the kfd process refcount and miss the NULL pointer check if app process is already destroyed.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: guard against EA inode refcount underflow in xattr update syzkaller found a path wheCVE-2025-40190 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: guard against EA inode refcount underflow in xattr update syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1). That lets the refcount underflow and we proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode <n> ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117 Make the invariant explicit: if the current refcount is non-positive, treat this as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. Delete the WARN_ONCE() as negative refcounts are now impossible; keep error reporting in ext4_error_inode(). This prevents the underflow and the follow-on orphan/cleanup churn.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeproCVE-2025-40189 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom Syzbot reported read of uninitialized variable BUG with following call stack. lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout ===================================================== BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline] BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline] lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766 lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707 Local variable sig.i.i created at: lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline] lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_bind+0x711/0x1690
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PCVE-2025-40188 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peeCVE-2025-40187 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().CVE-2025-40186 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1
In the Linux kernel, the following vulnerability has been resolved: tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). syzbot reported the splat below in tcp_conn_request(). [0] If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket. After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk. Let's remove reqsk_fastopen_remove() in tcp_conn_request(). Note that other callers make sure tp->fastopen_rsk is not NULL. [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Googl
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ice: ice_adapter: release xa entry on adapter allocation failure When ice_adapter_new() faCVE-2025-40185 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ice: ice_adapter: release xa entry on adapter allocation failure When ice_adapter_new() fails, the reserved XArray entry created by xa_insert() is not released. This causes subsequent insertions at the same index to return -EBUSY, potentially leading to NULL pointer dereferences. Reorder the operations as suggested by Przemek Kitszel: 1. Check if adapter already exists (xa_load) 2. Reserve the XArray slot (xa_reserve) 3. Allocate the adapter (ice_adapter_new) 4. Store the adapter (xa_store)
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix debug checking for np-guests using huge mappings When running with transpaCVE-2025-40184 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix debug checking for np-guests using huge mappings When running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then the debug checking in assert_host_shared_guest() fails on the launch of an np-guest. This WARN_ON() causes a panic and generates the stack below. In __pkvm_host_relax_perms_guest() the debug checking assumes the mapping is a single page but it may be a block map. Update the checking so that the size is not checked and just assumes the correct size. While we're here make the same fix in __pkvm_host_mkyoung_guest(). Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128 Info: Removed ghost socket file "/.lkvm//guest-128.sock". [ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088! [ 1406.521804] kvm [141]: nVHE call trace: [ 1406.521828] kvm [141]: [<ffff8000811676b4>] __kvm_nvhe_hyp_panic+0xb4/0xe8 [ 1406.521946] kvm [141]: [<ffff80008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c [ 1406.522049] kvm [141]: [<ffff80008116f068>] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104 [ 1406.522157] kvm [141]: [
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feaCVE-2025-40183 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: crypto: skcipher - Fix reqsize handling Commit afddce13ce81d ("crypto: api - Add reqsize tCVE-2025-40182 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: skcipher - Fix reqsize handling Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs [1] instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in skcipher algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [2] Add proper set_reqsize calls in the skcipher init function to properly initialize reqsize for these algorithms in the framework. [1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/ [2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an CVE-2025-40181 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM are enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a SystemMemory entry is present, then the kernel's ACPI driver will auto-ioremap the region so that it can be accessed at will. However, the ACPI spec doesn't provide a way to enumerate the memory type of SystemMemory regions, i.e. there's no way to tell software that a region must be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bar
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop wasCVE-2025-40180 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily lCVE-2025-40179 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pidCVE-2025-40178 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix bootlog initialization ordering As soon as we queue MHI buffers to receiveCVE-2025-40177 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix bootlog initialization ordering As soon as we queue MHI buffers to receive the bootlog from the device, we could be receiving data. Therefore all the resources needed to process that data need to be setup prior to queuing the buffers. We currently initialize some of the resources after queuing the buffers which creates a race between the probe() and any data that comes back from the device. If the uninitialized resources are accessed, we could see page faults. Fix the init ordering to close the race.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls CVE-2025-40176 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: idpf: cleanup remaining SKBs in PTP flows When the driver requests Tx timestamp value, oneCVE-2025-40175 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: idpf: cleanup remaining SKBs in PTP flows When the driver requests Tx timestamp value, one of the first steps is to clone SKB using skb_get. It increases the reference counter for that SKB to prevent unexpected freeing by another component. However, there may be a case where the index is requested, SKB is assigned and never consumed by PTP flows - for example due to reset during running PTP apps. Add a check in release timestamping function to verify if the SKB assigned to Tx timestamp latch was freed, and release remaining SKBs.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix SMP ordering in switch_mm_irqs_off() Stephen noted that it is possible to not CVE-2025-40174 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix SMP ordering in switch_mm_irqs_off() Stephen noted that it is possible to not have an smp_mb() between the loaded_mm store and the tlb_gen load in switch_mm(), meaning the ordering against flush_tlb_mm_range() goes out the window, and it becomes possible for switch_mm() to not observe a recent tlb_gen update and fail to flush the TLBs. [ dhansen: merge conflict fixed by Ingo ]
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updCVE-2025-40173 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_CVE-2025-40172 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: move lsop put work to nvmet_fc_ls_req_op It’s possible for more than one async cCVE-2025-40171 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: move lsop put work to nvmet_fc_ls_req_op It’s possible for more than one async command to be in flight from __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken. In the current code, only one put work item is queued at a time, which results in a leaked reference. To fix this, move the work item to the nvmet_fc_ls_req_op struct, which already tracks all resources related to the command.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_CVE-2025-40170 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size(). Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward(). ip4_dst_hoplimit() can use dst_dev_net_rcu().
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative offsets for ALU ops When verifying BPF programs, the check_alu_op() fCVE-2025-40169 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative offsets for ALU ops When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer. The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This commit tightens the validation by changing the condition to '(insn->off != 0 && insn->off != 1)'. This ensures that any value other than the explicitly permitted 0 and 1 is rejected, hardening the verifier against malformed BPF programs.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().CVE-2025-40168 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1
In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in exCVE-2025-40167 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Check GuC running state before deregistering exec queue In normal operation, aCVE-2025-40166 · 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/guc: Check GuC running state before deregistering exec queue In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: " [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] " v2: use xe_uc_fw_is_runni
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls arCVE-2025-40165 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23:
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the follCVE-2025-40164 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix using smp_processor_id() in preemptible code warnings Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Stop dl_server before CPU goes offline IBM CI tool reported kernel warningCVE-2025-40163 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Stop dl_server before CPU goes offline IBM CI tool reported kernel warning[1] when running a CPU removal operation through drmgr[2]. i.e "drmgr -c cpu -r -q 1" WARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170 NIP [c0000000002b6ed8] cpudl_set+0x58/0x170 LR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 Call Trace: [c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable) [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 [c00000000034df84] __hrtimer_run_queues+0x1a4/0x390 [c00000000034f624] hrtimer_interrupt+0x124/0x300 [c00000000002a230] timer_interrupt+0x140/0x320 Git bisects to: commit 4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck") This happens since: - dl_server hrtimer gets enqueued close to cpu offline, when kthread_park enqueues a fair task. - CPU goes offline and drmgr removes it from cpu_present_mask. - hrtimer fires and warning is hit. Fix it by stopping the dl_server before CPU is marked dead. [1]: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/ [2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails devm_kasprintf() may retCVE-2025-40162 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails devm_kasprintf() may return NULL on memory allocation failure, but the debug message prints cpus->dai_name before checking it. Move the dev_dbg() call after the NULL check to prevent potential NULL pointer dereference.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix SGI cleanup on unbind The driver incorrectly determines SGI vs SPCVE-2025-40161 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix SGI cleanup on unbind The driver incorrectly determines SGI vs SPI interrupts by checking IRQ number < 16, which fails with dynamic IRQ allocation. During unbind, this causes improper SGI cleanup leading to kernel crash. Add explicit irq_type field to pdata for reliable identification of SGI interrupts (type-2) and only clean up SGI resources when appropriate.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRCVE-2025-40160 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards. Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON(). A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid valuCVE-2025-40159 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit. desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks. Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already). bloat-o-meter reports a little growth of the code size: add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function old new delta xskq_cons_peek_desc 299 330 +31 xsk_tx_peek_release_desc_batch 973 1002 +29 xsk_generic_xmit
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU in ip6_output() Use RCU in ip6_output() in order to use dst_dev_rcu() to preCVE-2025-40158 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1
In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU in ip6_output() Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF. We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller When loading the i10nm_eCVE-2025-40157 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ... This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above. Fix this call trace by skipping DIMM enumeration on a disabled memory controller.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe() The drv->sram_reCVE-2025-40156 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe() The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check that the pointer is valid.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignoCVE-2025-40155 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.3
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> pgta
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping When an invalid value is passedCVE-2025-40154 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping When an invalid value is passed via quirk option, currently bytcr_rt5640 driver only shows an error message but leaves as is. This may lead to unepxected results like OOB access. This patch corrects the input mapping to the certain default value if an invalid value is passed.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: avoid soft lockup when mprotect to large memory area When calling mprotect() CVE-2025-40153 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: avoid soft lockup when mprotect to large memory area When calling mprotect() to a large hugetlb memory area in our customer's workload (~300GB hugetlb memory), soft lockup was observed: watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916] CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mte_clear_page_tags+0x14/0x24 lr : mte_sync_tags+0x1c0/0x240 sp : ffff80003150bb80 x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000 x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458 x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000 x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffc01ce7a5c00
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix bootup splat with separate_gpu_drm modparam The drm_gem_for_each_gpuvm_bo() cCVE-2025-40152 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix bootup splat with separate_gpu_drm modparam The drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses drm_gem_obj.gpuva.list, which is not initialized when the drm driver does not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms drm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam is set: [ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0 [ 9.523160] Mem abort info: [ 9.523161] ESR = 0x0000000096000006 [ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits [ 9.523165] SET = 0, FnV = 0 [ 9.523166] EA = 0, S1PTW = 0 [ 9.523167] FSC = 0x06: level 2 translation fault [ 9.523169] Data abort info: [ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000 [ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000 [ 9.523184] Internal error: Oops: 0000
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: No support of struct argument in trampoline programs The current implementCVE-2025-40151 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: No support of struct argument in trampoline programs The current implementation does not support struct argument. This causes a oops when running bpf selftest: $ ./test_progs -a tracing_struct Oops[#1]: CPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938 rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801 rcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4) Sending NMI from CPU 0 to CPUs 1: rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800 Stack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680 9000000085d88000 0000000000000000 0000000000000040 9000000087159350
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid migrating empty section It reports a bug from device w/ zufs: F2FS-fs CVE-2025-40150 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid migrating empty section It reports a bug from device w/ zufs: F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT F2FS-fs (dm-64): Stopped filesystem due to reason: 4 Thread A Thread B - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_gc_range - do_garbage_collect w/ segno #x - writepage - f2fs_allocate_data_block - new_curseg - allocate segno #x The root cause is: fallocate on pinning file may race w/ block allocation as above, result in do_garbage_collect() from fallocate() may migrate segment which is just allocated by a log, the log will update segment type in its in-memory structure, however GC will get segment type from on-disk SSA block, once segment type changes by log, we can detect such inconsistency, then shutdown filesystem. In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE), however segno #173822 was just allocated as data type segment, so in-memory SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA). Change as below to fix this issue: - check whether current section is empty before
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().CVE-2025-40149 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions The functCVE-2025-40148 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions The function dc_stream_set_cursor_attributes() currently dereferences the `stream` pointer and nested members `stream->ctx->dc->current_state` without checking for NULL. All callers of these functions, such as in `dcn30_apply_idle_power_optimizations()` and `amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks before calling these functions. Fixes below: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes() error: we previously assumed 'stream' could be null (see line 334) drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 327 bool dc_stream_program_cursor_attributes( 328 struct dc_stream_state *stream, 329 const struct dc_cursor_attributes *attributes) 330 { 331 struct dc *dc; 332 bool reset_idle_optimizations = false; 333 334 dc = stream ? stream->ctx->dc : NULL; ^^^^^^ The old code assumed stream could be NULL. 335 --> 336 if (dc_stream_set_cursor_attribu
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: blk-throttle: fix access race during throttle policy activation On repeated cold boots we CVE-2025-40147 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: blk-throttle: fix access race during throttle policy activation On repeated cold boots we occasionally hit a NULL pointer crash in blk_should_throtl() when throttling is consulted before the throttle policy is fully enabled for the queue. Checking only q->td != NULL is insufficient during early initialization, so blkg_to_pd() for the throttle policy can still return NULL and blkg_to_tg() becomes NULL, which later gets dereferenced. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000156 ... pc : submit_bio_noacct+0x14c/0x4c8 lr : submit_bio_noacct+0x48/0x4c8 sp : ffff800087f0b690 x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0 x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60 x8 : 00000a6fb8a86e85 x7 : 0000000000
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix potential deadlock while nr_requests grown Allocate and free sched_tags while CVE-2025-40146 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix potential deadlock while nr_requests grown Allocate and free sched_tags while queue is freezed can deadlock[1], this is a long term problem, hence allocate memory before freezing queue and free memory after queue is unfreezed. [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure When devm_add_actionCVE-2025-40145 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure When devm_add_action_or_reset() fails, it calls the passed cleanup function. Hence the caller must not repeat that cleanup. Replace the "goto err_regulator_free" by the actual freeing, as there will never be a need again for a second user of this label.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: bpf: dont report verifier bug for missing bpf_scc_visit on speculative path Syzbot generatCVE-2025-40143 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: dont report verifier bug for missing bpf_scc_visit on speculative path Syzbot generated a program that triggers a verifier_bug() call in maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a state with insn_idx in some SCC, there should be an instance of struct bpf_scc_visit allocated for that SCC. Turns out the assumption does not hold for speculative execution paths. See example in the next patch. maybe_scc_exit() is called from update_branch_counts() for states that reach branch count of zero, meaning that path exploration for a particular path is finished. Path exploration can finish in one of three ways: a. Verification error is found. In this case, update_branch_counts() is called only for non-speculative paths. b. Top level BPF_EXIT is reached. Such instructions are never a part of an SCC, so compute_scc_callchain() in maybe_scc_exit() will return false, and maybe_scc_exit() will return early. c. A checkpoint is reached and matched. Checkpoints are created by is_state_visited(), which calls maybe_enter_scc(), which allocates bpf_scc_visit instances for checkpoints within S
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Nov 12, 2025In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT snd_pcm_group_CVE-2025-40142 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts via spin_lock_irq(). This also implicitly disables the handling of softirqs such as TIMER_SOFTIRQ. On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not disable them. That means a timer can be invoked during spin_lock_irq() on the same CPU. Due to synchronisations reasons local_bh_disable() has a per-CPU lock named softirq_ctrl.lock which synchronizes individual softirq against each other. syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This is a possible deadlock. The softirq_ctrl.lock can not be made part of spin_lock_irq() as this would lead to too much synchronisation against individual threads on the system. To avoid the possible deadlock, softirqs must be manually disabled before the lock is acquired. Disable softirqs before the lock is acquired on PREEMPT_RT.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org

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.

Vulnerability database

The flaws that hit local websites, every Friday.

Tell us what you're building.