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,146 results · page 5 of 23
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: s390: Revert support for DCACHE_WORD_ACCESS load_unaligned_zeropad() reads eight bytes froCVE-2026-64369 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: s390: Revert support for DCACHE_WORD_ACCESS load_unaligned_zeropad() reads eight bytes from unaligned addresses and may cross page boundaries. It handles exceptions which may happen if reading from the second page results in an exception. For pages which are donated to the Ultravisor for secure execution purposes the do_secure_storage_access() exception handler however does not handle such exceptions correctly. Such an exception may result in an endless exception loop which will never be resolved. An attempt to fix this [1] turned out to be not sufficient. For now revert load_unaligned_zeropad() until this problem has been resolved in a proper way. Note that the implementation of load_unaligned_zeropad() itself is correct. The revert is just a temporary workaround until there is complete fix for secure storage access exceptions. [1] commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory")
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled When init (zeroCVE-2026-64368 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1
In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s __GFP_ZERO guarantees. But if we track the requested size, krealloc() uses that information to do the right thing, so we can zero only the requested size. With red zoning also enabled, any extra size became part of the red zone, so it must not be zeroed and thus we must zero only the requested size. However the current check is imprecise, and will trigger also when only SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s __GFP_ZERO contract. Fix this by using slub_debug_orig_size() instead, which is the exact check for whether the requested size is tracked. We don't need to care if red zoning is also enabled or not. Also update and expand the comment accordingly.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early wiCVE-2026-64360 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad CVE-2026-64275 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 24, 2026In the Linux kernel, the following vulnerability has been resolved: i2c: davinci: fix division by zero on missing clock-frequency When the 'clock-frequency' pCVE-2026-64236 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: i2c: davinci: fix division by zero on missing clock-frequency When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz. The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->bus_freq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence. Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 22, 2026In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set to any value greater than zero), glue records of 0.0.0CVE-2026-50251 · Other software · NLnet Labs · reported by sep@nlnetlabs.nlMedium 5.3
In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and 127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The counter resets to zero on every cache flush, so the atta
- Product
- Unbound
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 21, 2026In Eclipse OMR versions up to 0.11, the arraycmp SIMD implementation for Z and P does not check if the number of bytes to compare is zero.CVE-2026-16243 · Other software · Eclipse Foundation · reported by emo@eclipse.orgMedium 5.7
In Eclipse OMR versions up to 0.11, the arraycmp SIMD implementation for Z and P does not check if the number of bytes to compare is zero.
- Product
- Eclipse OMR
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 20, 2026nono is software that allows users to run AI agents in a zero-latency sandbox.CVE-2026-47128 · Other software · always-further · reported by GitHubMedium 6.1
nono is software that allows users to run AI agents in a zero-latency sandbox. Prior to version 0.55.0, the nono Landlock/seccomp policies allow access to local Unix domain sockets (concrete and abstract). This allows an easy sandbox escape by talking to the per-user systemd dbus socket. Version 0.55.0 patches the issue.
- Product
- nono
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential for tearing in ->remote_i_size and ->zero_point Fix potential tearingCVE-2026-64160 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential for tearing in ->remote_i_size and ->zero_point Fix potential tearing in using ->remote_i_size and ->zero_point by copying i_size_read() and i_size_write() and using the same seqcount as for i_size. We need to make sure that netfslib and the filesystems that use it always hold i_lock whilst updating any of the sizes to prevent i_size_seqcount from getting corrupted.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: netfs: Fix zeropoint update where i_size > remote_i_size Fix the update of the zero point[CVE-2026-64159 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix zeropoint update where i_size > remote_i_size Fix the update of the zero point[*] by netfs_release_folio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. i_size > remote_i_size). The update needs to limit zero_point to remote_i_size, not i_size as i_size is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remote_i_size tracks the server's i_size. [*] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads. Note that netfs_invalidate_folio() probably doesn't need fixing as zero_point should be updated by setattr after truncation or fallocate. Found with: fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops using the following as junk.fsxops: truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copy_range 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free __GFP_ZCVE-2026-64130 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: bind uarg before filling zerocopy skb virtio_transport_send_pkt_info() allocCVE-2026-63970 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: bind uarg before filling zerocopy skb virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg before entering the send loop, but virtio_transport_alloc_skb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfree_skb() to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so skb_release_data() falls through to ordinary frag unref. Pass the uarg into virtio_transport_alloc_skb() and bind it immediately before virtio_transport_fill_skb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: auxdisplay: line-display: fix OOB read on zero-length message_store() linedisp_display() uCVE-2026-63949 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: auxdisplay: line-display: fix OOB read on zero-length message_store() linedisp_display() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]: write(fd, "", 0); -> message_store(..., buf, count=0) -> linedisp_display(linedisp, buf, count=0) -> msg[count - 1] == '\n' ; OOB read The kernfs write buffer for that store is a 1-byte allocation (kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0), so msg[-1] is a 1-byte read before the slab object. On a KASAN-enabled kernel this trips an out-of-bounds report and panics; on stock kernels it silently reads adjacent slab data and, if that byte happens to be '\n', the following count-- wraps ssize_t 0 to -1 and is then passed to kmemdup_nul(). linedisp_display() is reached from the message_store() sysfs callback (drivers/auxdisplay/line-display.c message attribute, mode 0644) and from the in-tree initial-message setup with count == -1, so the OOB path is only userspace-triggerable via zero-byte writes; vfs_write() does not short-circuit on count == 0 and ke
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: iio: adc: nxp-sar-adc: fix division by zero in write_raw Add a validation check for the saCVE-2026-63935 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: iio: adc: nxp-sar-adc: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero or a negative value to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Also prevent unsigned integer underflow when the computed cycle count is smaller than NXP_SAR_ADC_CONV_TIME, which would wrap the u32 inpsamp to a huge value.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: iio: gyro: adis16260: fix division by zero in write_raw Add a validation check for the samCVE-2026-63933 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: iio: gyro: adis16260: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero to the sampling_frequency sysfs attribute triggers a division by zero in the kernel.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: fix division by zero in write_raw Add a zero check for val2 before uCVE-2026-63931 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: fix division by zero in write_raw Add a zero check for val2 before using it as a divisor when setting the sampling frequency. A user writing a zero fractional part to the sampling_frequency sysfs attribute triggers a division by zero in the kernel.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname A reader in l2tp_session_getCVE-2026-63918 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname A reader in l2tp_session_get_by_ifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcount_inc(), but every other session getter in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the corresponding _get_next variants) uses refcount_inc_not_zero() because the IDR/RCU lookup can race with refcount_dec_and_test() -> l2tp_session_free() -> kfree_rcu(). The ifname getter is the only outlier; the inconsistency was raised on-list after 979c017803c4 ("l2tp: use list_del_rcu in l2tp_session_unhash"). A reader inside rcu_read_lock_bh() that matches session->ifname can be preempted between the strcmp() and the refcount_inc(). If the last reference drops on another CPU in that window, the reader's refcount_inc() runs on a counter that has reached zero. refcount_t catches the addition-on-zero, prints "refcount_t: addition on 0; use-after-free", saturates the counter, and returns the saturated pointer to the caller. Session memory is held live by the in-flight RCU read section, but the
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker drivers/scsi/fcoe/fcoeCVE-2026-63890 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker drivers/scsi/fcoe/fcoe_ctlr.c::fcoe_ctlr_recv_clr_vlink() advanced the descriptor cursor by an attacker-supplied fip_dlen without ever requiring dlen >= sizeof(struct fip_desc) in the default branch. The named descriptor cases (FIP_DT_MAC, FIP_DT_NAME, FIP_DT_VN_ID) checked their per-type minimum lengths, but a FIP_DT_NON_CRITICAL descriptor (fip_dtype >= 128, which the standard requires receivers to silently ignore) skipped that check entirely. An unauthenticated L2 peer on the FCoE control VLAN could hang fcoe_ctlr_recv_work on an fcoe, qedf, or bnx2fc initiator indefinitely by emitting one FIP CVL frame whose single descriptor had fip_dtype == FIP_DT_NON_CRITICAL and fip_dlen == 0: the cursor advanced zero bytes per iteration and the loop condition rlen >= sizeof(*desc) stayed true forever, blocking every subsequent FIP frame on that controller. Tighten the outer dlen guard to also reject dlen < sizeof(struct fip_desc), so a malformed descriptor whose length cannot even cover the descriptor header is rejected before the switch. This is the
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= CVE-2026-63836 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the fCVE-2026-53392 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() dCVE-2026-53391 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its "*str = NULL; return ret" tail, leaving buf NULL with a return value of 0. The "< 0" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping bCVE-2026-53374 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 17, 2026Zeroconf is a pure Python implementation of multicast DNS service discovery.CVE-2026-48487 · Other software · python-zeroconf · reported by GitHubMedium 5.3
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.16, _read_character_string and _read_string in src/zeroconf/_protocol/incoming.py advanced self.offset by attacker-declared RDLENGTH without checking it against self._data_len, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to send a TXT, HINFO, or A/AAAA record with rdlength=65535 and seed DNSCache and ServiceInfo.properties with truncated, attacker-shaped key/value or address records. This issue is fixed in version 0.149.16.
- Product
- python-zeroconf
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 17, 2026Zeroconf is a pure Python implementation of multicast DNS service discovery.CVE-2026-48045 · Other software · python-zeroconf · reported by GitHubMedium 6.5
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.12, AsyncListener.handle_query_or_defer retained every truncated TC-bit incoming query, each up to _MAX_MSG_ABSOLUTE = 8966 bytes, in self._deferred[addr] and armed a per-address timer in self._timers[addr] without capping the per-address list or distinct addr keys, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to spoof sources, grow _deferred and _timers, and cause memory exhaustion and quadratic CPU burn. This issue is fixed in version 0.149.12.
- Product
- python-zeroconf
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 17, 2026Zeroconf is a pure Python implementation of multicast DNS service discovery.CVE-2026-47184 · Other software · python-zeroconf · reported by GitHubMedium 6.5
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.7, DNSCache._async_add inserted every response record into cache, _expirations, _expire_heap, and service_cache without a cap, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to multicast valid mDNS responses with unique names and cause memory exhaustion, slower cache lookups, slower async_expire passes, and broken discovery, registration, and ServiceBrowser callbacks. This issue is fixed in version 0.149.7.
- Product
- python-zeroconf
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 17, 2026Zeroconf is a pure Python implementation of multicast DNS service discovery.CVE-2026-47183 · Other software · python-zeroconf · reported by GitHubMedium 6.5
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.6, DNSIncoming._log_exception_debug and the four QuietLogger exception-dedup methods stored an unbounded _seen_logs dictionary keyed by attacker-influenced IncomingDecodeError messages, retaining sys.exc_info() tracebacks whose frame locals kept raw packet self.data buffers and allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to drive memory growth until mDNS-dependent features degrade or the process is OOM-killed. This issue is fixed in version 0.149.6.
- Product
- python-zeroconf
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 17, 2026Zeroconf is a pure Python implementation of multicast DNS service discovery.CVE-2026-47180 · Other software · python-zeroconf · reported by GitHubMedium 6.5
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.5, DNSIncoming._decode_labels_at_offset recurses once per DNS-name compression pointer, and a single mDNS packet carrying chained pointers can trigger a RecursionError that escapes DNSIncoming.__init__, causing sustained CPU burn, log flooding, and degraded mDNS-dependent features for unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb). This issue is fixed in version 0.149.5.
- Product
- python-zeroconf
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 16, 2026A divide-by-zero vulnerability in the Productivity Suite allows a local attacker to cause a division by zero leading to a system crash.CVE-2026-61378 · Other software · AutomationDirect · reported by ics-cert@hq.dhs.govMedium 6.8
A divide-by-zero vulnerability in the Productivity Suite allows a local attacker to cause a division by zero leading to a system crash.
- Product
- Productivity Suite
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comautomationdirect.com
Jul 16, 2026SGLang uses an expert-parallel backup subsystem that exposes a ZeroMQ PULL socket on a routable network interface that does not contain authentication or deseriCVE-2026-14890 · Other software · SGLang · reported by cret@cert.orgCritical 9.1
SGLang uses an expert-parallel backup subsystem that exposes a ZeroMQ PULL socket on a routable network interface that does not contain authentication or deserialization safeguards, allowing an attacker to provide a malicious pickle file that results in unauthenticated remote code execution when the feature is enabled and the service is reachable over the network.
- Product
- SGLang
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordvince.cert.orggithub.com
Jul 14, 2026NVIDIA TensorRT-LLM for any platform contains a vulnerability in visual gen server, where an attacker could cause an unsafe deserialization by unauthorized zeroCVE-2026-24220 · Other software · NVIDIA · reported by psirt@nvidia.comMedium 6.4
NVIDIA TensorRT-LLM for any platform contains a vulnerability in visual gen server, where an attacker could cause an unsafe deserialization by unauthorized zeroMQ deserialization. A successful exploit of this vulnerability might lead to code execution.
- Product
- TensorRT-LLM
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 13, 2026In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmentCVE-2026-53365 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was pre-existing.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jul 12, 2026A vulnerability was detected in AojiaoZero Antaris 1.0.CVE-2026-15502 · Other software · AojiaoZero · reported by VulDBMedium 5.3
A vulnerability was detected in AojiaoZero Antaris 1.0. This affects the function _rewardPurchase of the file /ipn.php of the component PayPal IPN Payment Handler. The manipulation of the argument item_number results in sql injection. The attack may be performed from remote. The vendor was contacted early about this disclosure but did not respond in any way.
- Product
- Antaris
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 1, 2026A division-by-zero vulnerability in the CStreamSwitcherOutputPin::DecideBufferSize function of Aleksoid1978 MPC-BE before commit 4341cb3 allows attackers to cauCVE-2026-36911 · Other software · reported by MITREMedium 5.5
A division-by-zero vulnerability in the CStreamSwitcherOutputPin::DecideBufferSize function of Aleksoid1978 MPC-BE before commit 4341cb3 allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 1, 2026FatFs R0.16 and earlier contains an uninitialized cluster exposure when f_lseek() extends files beyond EOF without zero-filling newly allocated clusters.CVE-2026-6686 · Other software · ChaN · reported by 44488dab-36db-4358-99f9-bc116477f914Medium 4.6
FatFs R0.16 and earlier contains an uninitialized cluster exposure when f_lseek() extends files beyond EOF without zero-filling newly allocated clusters. This maps to CWE-908 (Use of Uninitialized Resource). Estimated CVSS v3.1 vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (4.6, Medium). The estimated CISA SSVC vectors are Exploitation: PoC, Technical Impact: Partial.
- Product
- FatFs
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordelm-chan.orggithub.com
Jul 1, 2026FatFs R0.16 and earlier contains a divide-by-zero in exFAT sync logic bug when crafted metadata causes n_fatent - 2 to be zero during write/sync operations.CVE-2026-6683 · Other software · ChaN · reported by 44488dab-36db-4358-99f9-bc116477f914Medium 4.6
FatFs R0.16 and earlier contains a divide-by-zero in exFAT sync logic bug when crafted metadata causes n_fatent - 2 to be zero during write/sync operations. This maps to CWE-369 (Divide By Zero). Estimated CVSS v3.1 vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (4.6, Medium). Network-delivered update media can make this remote in some pipelines. The estimated CISA SSVC vectors are Exploitation: PoC, Technical Impact: Partial.
- Product
- FatFs
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordelm-chan.orggithub.com
Jun 30, 2026ImageMagick before 7.1.2-22 contains a division by zero vulnerability in binomial kernel processing that allows attackers to cause denial of service.CVE-2026-56363 · Other software · ImageMagick · reported by VulnCheckMedium 4.8
ImageMagick before 7.1.2-22 contains a division by zero vulnerability in binomial kernel processing that allows attackers to cause denial of service. An attacker can supply a large binomial kernel value causing integer overflow, resulting in division by zero and application crash.
- Product
- ImageMagick
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comvulncheck.com
Jun 27, 2026libssh2 through 1.11.1 grows its publickey list with SSH2_REALLOC but does not zero-initialize new entries before parsing populates them, so a parse failure reaCVE-2026-58051 · Other software · libssh2 · reported by VulnCheckHigh 8.3
libssh2 through 1.11.1 grows its publickey list with SSH2_REALLOC but does not zero-initialize new entries before parsing populates them, so a parse failure reaching the cleanup path leaves libssh2_publickey_list_free operating on an uninitialized entry. A malicious SSH server offering the publickey subsystem can use a malformed response to make cleanup free an uninitialized, attacker-influenceable attrs pointer in a connecting libssh2 client.
- Product
- libssh2
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jun 26, 2026In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocksCVE-2026-53320 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 25, 2026HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification.CVE-2026-6331 · Other software · wolfSSL · reported by facts@wolfssl.comLow 2.1
HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length and rejects a zero-length MAC, so a forged short or empty tag is no longer accepted.
- Product
- wolfSSL
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jun 25, 2026In EmberZNet v9.0.2 and earlier, a malformed Level Control Step command can terminate the process through a divide-by-zero fault.CVE-2026-47153 · Other software · Silicon Labs · reported by product-security@silabs.comHigh 7.1
In EmberZNet v9.0.2 and earlier, a malformed Level Control Step command can terminate the process through a divide-by-zero fault. This command must come from a device that has already joined the network. Only devices supporting the Level Control cluster may be impacted.
- Product
- EmberZNet
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comsiliconlabs.lightning.force.com
Jun 25, 2026In EmberZNet v9.0.2 and earlier, a malformed Level Control Move command can terminate the process through a divide-by-zero fault.CVE-2026-47152 · Other software · Silicon Labs · reported by product-security@silabs.comHigh 7.1
In EmberZNet v9.0.2 and earlier, a malformed Level Control Move command can terminate the process through a divide-by-zero fault. This command must come from a device that has already joined the network. Only devices supporting the Level Control cluster may be impacted.
- Product
- EmberZNet
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comsiliconlabs.lightning.force.com
Jun 25, 2026ECS zero scoped answers are stored in the packet cache while they should not.CVE-2026-40012 · Other software · PowerDNS · reported by security@open-xchange.comMedium 5.3
ECS zero scoped answers are stored in the packet cache while they should not. This impacts only configurations that have ECS enabled;
- Product
- Recursor
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(caCVE-2026-53174 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() acCVE-2026-53150 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_couCVE-2026-53140 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workCVE-2026-53139 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Zero-extend bpf prog return values and kfunc arguments s390x ABI requires callerCVE-2026-53110 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Zero-extend bpf prog return values and kfunc arguments s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in nCVE-2026-53029 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of "*len" 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at: ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() CVE-2026-52995 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_t
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting virtio_transport_init_zcopy_skb() uCVE-2026-52994 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting virtio_transport_init_zcopy_skb() uses iter->count as the size argument for msg_zerocopy_realloc(), which in turn passes it to mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this function is called after virtio_transport_fill_skb() has already consumed the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count will be 0, skipping the RLIMIT_MEMLOCK enforcement. Pass pkt_len (the total bytes being sent) as an explicit parameter to virtio_transport_init_zcopy_skb() instead of reading the already-consumed iter->count. This matches TCP and UDP, which both call msg_zerocopy_realloc() with the original message size.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.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.
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.
Not ready to talk yet? Run the free website check and see what Google sees.