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.
210 results · page 1 of 5
Nov 2, 2026In validateImageInfo of Bitmap.cpp, there is a possible out-of-bounds read due to a precondition check failure.CVE-2026-58997 · Computers, phones & browsers · Google · reported by security@android.com
In validateImageInfo of Bitmap.cpp, there is a possible out-of-bounds read due to a precondition check failure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
- Product
- Android
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 30, 2026Scribus before 1.6.7 and 1.7.x before 1.7.4 contains an out-of-bounds memory access vulnerability in the importsvm plugin that fails to verify bitmap and transpCVE-2026-104067 · Other software · Scribus · reported by VulnCheckHigh 8.5
Scribus before 1.6.7 and 1.7.x before 1.7.4 contains an out-of-bounds memory access vulnerability in the importsvm plugin that fails to verify bitmap and transparency mask dimensions match. Attackers can supply a crafted SVM file with mismatched mask dimensions to trigger heap reads and writes, causing crashes or code execution as the user.
- Product
- Scribus
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 19, 2026rdesktop through 1.9.0 contains a heap out-of-bounds read vulnerability in process_plane() in bitmap.c that allows malicious RDP servers to crash clients by senCVE-2026-112277 · Other software · rdesktop · reported by VulnCheckHigh 7.1
rdesktop through 1.9.0 contains a heap out-of-bounds read vulnerability in process_plane() in bitmap.c that allows malicious RDP servers to crash clients by sending malformed 32 bpp compressed bitmaps. Attackers can declare a large bitmap geometry with a short compressed body in bitmap update PDUs or bitmap cache orders, causing unbounded reads past the receive buffer and denial of service.
- Product
- rdesktop
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified Force a refreshCVE-2026-98720 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR.
- 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
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSRCVE-2026-98716 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12. Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information.
- 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
Oct 13, 2026FreeRDP 3.27.1 before 3.32.0 contains a NULL pointer dereference in update_read_cache_bitmap_v3_order() in libfreerdp/core/orders.c, which accesses the client bCVE-2026-109939 · Other software · FreeRDP · reported by VulnCheckHigh 7.1
FreeRDP 3.27.1 before 3.32.0 contains a NULL pointer dereference in update_read_cache_bitmap_v3_order() in libfreerdp/core/orders.c, which accesses the client bitmap cache when the CBR3_DO_NOT_CACHE flag is set, even though the cache is not yet initialized before Demand Active. A malicious or compromised RDP server can send a Cache Bitmap V3 order during connection setup to crash a connecting client that has enabled the non-default Bitmap Cache V3 feature (/cache:codec:<rfx|nsc|jpeg>).
- Product
- FreeRDP
- 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
Sep 29, 2026U-Boot through 2026.10-rc5 contains an out-of-bounds write vulnerability in the video_display_rle8_bitmap function in drivers/video/video_bmp.c.CVE-2026-71972 · Other software · u-boot · reported by VulnCheckMedium 6
U-Boot through 2026.10-rc5 contains an out-of-bounds write vulnerability in the video_display_rle8_bitmap function in drivers/video/video_bmp.c. Attackers can supply a crafted RLE8-compressed BMP image to corrupt memory adjacent to the framebuffer and crash the bootloader.
- Product
- u-boot
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: store available counter mask as bitmap The available-counter mask was a singCVE-2026-97587 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: store available counter mask as bitmap The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]
- 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
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: xfs: destroy seen inode bitmap when we fail to add a dirpath LOLLM observes a memory leak CVE-2026-97543 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: xfs: destroy seen inode bitmap when we fail to add a dirpath LOLLM observes a memory leak in xchk_dirtree_create_path if we create the directory path object but appending the name to the path fails. When this happens, we don't tear down the (empty) seen inode bitmap. This is a pretty trivial error, but let's not leave logic bombs. Do the same for a similar bug in xrep_dirtree_create_adoption_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
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: xfs: bail out on bitmap errors in xrep_agfl_fill LOLLM also points out that the xagb_bitmaCVE-2026-97542 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: xfs: bail out on bitmap errors in xrep_agfl_fill LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill can fail, but we don't check the result of xagb_bitmap_walk, so we silently drop the error and proceed with inconsistent incore data. That shouldn't be allowed.
- 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
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking qla25xx_free_req_que() CVE-2026-97537 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que(): 1. When dma_alloc_coherent() fails during queue creation, the error path calls the free function with req->ring / rsp->ring still NULL (from kzalloc). The unconditional dma_free_coherent() with a NULL cpu_addr is undefined behavior and can panic. 2. The free functions clear req_qid_map / rsp_qid_map under vport_lock, but the create functions protect the same bitmaps with mq_lock. This provides no mutual exclusion. Additionally, the create error path clears the bit and releases mq_lock before calling the free function, creating a window where another thread can allocate the same que_id and have its ha->req_q_map entry clobbered by the subsequent lockless NULL assignment in the free function. Fix by: - Guarding dma_free_coherent() with a NULL check on the ring pointer. - Using mq_lock (the lock held by all creators) in the free functions to atomically NULL the map
- 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
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size The VP control IOCB selectsCVE-2026-97535 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array. max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout). Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected.
- 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
Sep 24, 2026In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap The DECLARE_BITMAP(apCVE-2026-93238 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero().
- 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
Sep 23, 2026A heap-based out-of-bounds write vulnerability exists in Foxit PDF Editor/Reader’s WebP image decoding due to improper handling of bitmap stride and target buffCVE-2026-91802 · Other software · Foxit Software Inc. · reported by 14984358-7092-470d-8f34-ade47a7658a2High 7.8
A heap-based out-of-bounds write vulnerability exists in Foxit PDF Editor/Reader’s WebP image decoding due to improper handling of bitmap stride and target buffer formats. Successful exploitation could result in an application crash.
- Product
- Foxit PDF Editor
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array bCVE-2026-90390 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states.
- 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
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the aCVE-2026-90279 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024).
- 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
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap beforCVE-2026-90278 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.
- 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
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: prevent create failure bitmap UAF llbitmap_create() publishes mddev->bitmaCVE-2026-90277 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: prevent create failure bitmap UAF llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap.
- 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
Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: stop daemon timer rearm on destroy llbitmap_destroy() deletes pending_timeCVE-2026-90276 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: stop daemon timer rearm on destroy llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk.
- 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
Sep 16, 2026In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocaCVE-2026-89953 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.
- 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
Sep 11, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the free-cluster bitmap scan to the volume vol->lcn_empty_bits_per_page is sizCVE-2026-89614 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the free-cluster bitmap scan to the volume vol->lcn_empty_bits_per_page is sized from vol->nr_clusters at mount, but ntfs_cluster_alloc() bounds its scan of that array by the size of $Bitmap. Those are independent on-disk quantities and the mount-time check only rejects a $Bitmap that is too small, so an image whose $Bitmap covers more clusters than the volume has lets the scan index past the array. A run whose LCN lies in that gap takes the allocator straight there, since the caller passes the file's own last LCN as its locality hint. KASAN reports a slab out-of-bounds read when a file on such a volume is extended. Clamp the scan to what that array covers, mirroring the max_index calculation the mount-time scan already uses, and reject a decoded LCN at or beyond nr_clusters in the mapping pairs decoder. Conforming volumes are unaffected.
- 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
Sep 10, 2026fs_read_glyphs() in the libXfont2 font-server client (src/fc/fserve.c) indexes the per-character encoding[] array using num_chars from the FS_QueryXBitmaps16 reCVE-2026-59679 · Other software · SUSE · reported by meissner@suse.deCritical 9.2
fs_read_glyphs() in the libXfont2 font-server client (src/fc/fserve.c) indexes the per-character encoding[] array using num_chars from the FS_QueryXBitmaps16 reply, but that array was allocated with a size derived from num_extents in the separate FS_QueryXExtents16 reply. The two CARD32 fields are never cross-checked. A malicious or compromised font server can send a small num_extents (e.g. 1) in the extents reply, then a large num_chars (e.g. 100000) in the bitmaps reply. This causes attacker-controlled out-of-bounds heap read and writes.
- Product
- Container suse/kiosk/tigervnc-x11vnc:1.14-63.8
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 10, 2026fs_read_glyphs() in the libXfont2 font-server client (src/fc/fserve.c) copies each glyph's bitmap into a single buffer.CVE-2026-44950 · Other software · SUSE · reported by meissner@suse.deCritical 9.5
fs_read_glyphs() in the libXfont2 font-server client (src/fc/fserve.c) copies each glyph's bitmap into a single buffer. Existing checks validates only that the source slice (position, length) lies within the source bitmap buffer. It does not check whether the running destination cursor has exceeded the allocation. A malicious font server can send overlapping source offsets -- for example 1000 glyphs each referencing {position:0, length:64} with nbytes=64. Each individual source range passes the existing validation, but the cumulative writes total 64000 bytes into a 64-byte destination buffer. This is a heap buffer overflow with attacker-controlled content.
- Product
- Container suse/kiosk/tigervnc-x11vnc:1.14-63.8
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chuCVE-2026-80718 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue.
- 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
Aug 26, 2026In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays eachCVE-2026-80536 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4
In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base, nbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recov
- 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
Aug 25, 2026The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2_init_fs() (subsys/fs/ext2/ext2_impl.c) by passing fs_blocks = s_blocks_count - s_fiCVE-2026-13478 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.5
The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2_init_fs() (subsys/fs/ext2/ext2_impl.c) by passing fs_blocks = s_blocks_count - s_first_data_block to ext2_bitmap_count_set(). That helper (subsys/fs/ext2/ext2_bitmap.c) treats its argument as a number of bits and reads one bitmap byte per eight bits, but the bitmap buffer (BGROUP_BLOCK_BITMAP) is a single fetched block of only fs->block_size bytes (capacity fs->block_size * 8 bits). s_blocks_count and s_first_data_block are taken verbatim from the superblock and were never bounded against this single-group capacity; ext2_verify_disk_superblock() checks the magic, revision, and block-size shift but not the block count. A crafted ext2 image with an oversized s_blocks_count (up to ~4 billion, against a maximum 4096-byte block / 32768-bit bitmap) makes ext2_bitmap_count_set() scan roughly 512 MB of memory past the bitmap block — a large out-of-bounds read of the static block slab and adjacent memory. The defect is reached during mount: ext2_init_fs() is invoked from ext2_mount() (subsys/fs/ext2/ext2_ops.c), the registered .mount operation. Any path that mounts an attacker-supplied ext2 image (removable media
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: minix: avoid overflow in bitmap block count calculation minix_check_superblock() uses miniCVE-2026-72369 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: minix: avoid overflow in bitmap block count calculation minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts. The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated. Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking the kernel. The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot ove
- 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
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: make system files immutable to prevent corruption When a system file such as $BitmapCVE-2026-72186 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1
In the Linux kernel, the following vulnerability has been resolved: ntfs: make system files immutable to prevent corruption When a system file such as $Bitmap is exposed via show_sys_files and written from userspace, the volume is corrupted and, because the cluster allocator scans $Bitmap through the same inode's page cache, a write to $Bitmap also deadlocks writeback against the folio it already holds locked. These files are maintained by the driver itself and have no valid reason to be written through the file interface. Mark base metadata files (mft_no < FILE_first_user) as immutable during inode read so the VFS rejects write, mmap, truncate and unlink with -EPERM. Directories are skipped so the root and $Extend remain usable. Internal metadata updates do not go through the VFS write path and are unaffected.
- 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
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Free BPID bitmap on setup failure nix_setup_bpids() allocates bp->bpids withCVE-2026-72050 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Free BPID bitmap on setup failure nix_setup_bpids() allocates bp->bpids with rvu_alloc_bitmap(), which uses a plain kcalloc(). If any of the following devm_kcalloc() allocations for the BPID mapping arrays fails, the function returns without freeing the bitmap. Free the BPID bitmap before returning from those error paths.
- 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
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracksCVE-2026-68292 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF V
- 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
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifsCVE-2026-68145 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.
- 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
Aug 1, 2026FreeRDP versions 3.28.0 and earlier contain an out-of-bounds read vulnerability in the RDP6 planar RLE bitmap decoder functions planar_decompress_plane_rle and CVE-2026-67306 · Other software · FreeRDP · reported by VulnCheckMedium 5.3
FreeRDP versions 3.28.0 and earlier contain an out-of-bounds read vulnerability in the RDP6 planar RLE bitmap decoder functions planar_decompress_plane_rle and planar_decompress_plane_rle_only in libfreerdp/codec/planar.c. Only the 1-byte control byte is bounds-checked; the subsequent 0–15 attacker-declared raw bytes are read without validating that the source buffer contains them. A malicious or compromised RDP server can send a truncated planar-encoded bitmap or surface update (reachable via both the Bitmap Update PDU and RDPGFX Surface Command paths) that causes the client to read past the end of the source buffer. The issue is fixed in FreeRDP 3.29.0.
- Product
- FreeRDP
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Jul 21, 2026Data::RoaringBitmap::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.CVE-2026-65065 · Other software · EGOR · reported by 9b29abf9-4ab0-4765-b253-1875cd9b441eMedium 5.5
Data::RoaringBitmap::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW. The segment is created in roaring.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing. A "Shared" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.
- Product
- Data::RoaringBitmap::Shared
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordmetacpan.orgmetacpan.org
Jul 21, 2026Data::RoaringBitmap::Shared versions before 0.02 for Perl allow an out-of-bounds read via an unvalidated container offset and cardinality in rb_contains_locked.CVE-2026-59143 · Other software · EGOR · reported by 9b29abf9-4ab0-4765-b253-1875cd9b441eMedium 6.3
Data::RoaringBitmap::Shared versions before 0.02 for Perl allow an out-of-bounds read via an unvalidated container offset and cardinality in rb_contains_locked. The attach-time validator rb_validate_header checks the header scalars and region layout against the file size, but does not validate the bucket contents it then trusts. rb_contains_locked forms a container pointer as pool + container_off * 8192 from a raw file-stored offset and then searches over a file-stored cardinality, neither bounded against the container pool capacity or the fixed 8192-byte slot size. A local peer that can write the backing file can leave the header valid while poisoning a bucket, so the next membership query dereferences a file-controlled wild pointer and scans a file-controlled count, reading adjacent memory or crashing the process.
- Product
- Data::RoaringBitmap::Shared
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordmetacpan.orgmetacpan.org
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap Sashiko pointed out that the driCVE-2026-64151 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4
In the Linux kernel, the following vulnerability has been resolved: iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap Sashiko pointed out that the driver could drop PAGE_SIZE from the pgsize_bitmap. That is technically allowed but nothing does it, and such an iommu_domain would not be used with the DMA API today. Still, it is against the design and it is trivial to fix up. Lift the PT_WARN_ON to the if branch and just skip the fast 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
Jul 19, 2026In the Linux kernel, the following vulnerability has been resolved: qed: fix double free in qed_cxt_tables_alloc() If one of the later PF or VF CID bitmap allCVE-2026-64118 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4
In the Linux kernel, the following vulnerability has been resolved: qed: fix double free in qed_cxt_tables_alloc() If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again. Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3. Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.
- 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: hpfs: fix a crash if hpfs_map_dnode_bitmap fails If hpfs_map_dnode_bitmap fails, the code CVE-2026-63954 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: hpfs: fix a crash if hpfs_map_dnode_bitmap fails If hpfs_map_dnode_bitmap fails, the code would call hpfs_brelse4 on uninitialized quad buffer head, causing a crash.
- 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: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of theCVE-2026-63830 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.4
In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.
- 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: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bgCVE-2026-63796 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8
In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2
- 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 8, 2026A heap buffer overflow in BitmapScaleBitmaps in libXfont2 before 2.0.8 due to an overflowing 32bit size could be used by attackers able to access the X Server tCVE-2026-56001 · Other software · X.Org · reported by meissner@suse.deHigh 8.5
A heap buffer overflow in BitmapScaleBitmaps in libXfont2 before 2.0.8 due to an overflowing 32bit size could be used by attackers able to access the X Server to execute code within the X server cont
- Product
- libXfont2
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgitlab.freedesktop.orgopenwall.com
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: raise barrier before state machine transition Move the barrier raise operaCVE-2026-46095 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: raise barrier before state machine transition Move the barrier raise operation before calling llbitmap_state_machine() in both llbitmap_start_write() and llbitmap_start_discard(). This ensures the barrier is in place before any state transitions occur, preventing potential race conditions where the state machine could complete before the barrier is properly raised.
- 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
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: skip reading rdevs that are not in_sync When reading bitmap pages from memCVE-2026-46045 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: skip reading rdevs that are not in_sync When reading bitmap pages from member disks, the code iterates through all rdevs and attempts to read from the first available one. However, it only checks for raid_disk assignment and Faulty flag, missing the In_sync flag check. This can cause bitmap data to be read from spare disks that are still being rebuilt and don't have valid bitmap information yet. Reading stale or uninitialized bitmap data from such disks can lead to incorrect dirty bit tracking, potentially causing data corruption during recovery or normal operation. Add the In_sync flag check to ensure bitmap pages are only read from fully synchronized member disks that have valid bitmap data.
- 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
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: fix percpu_ref not resurrected on suspend timeout When llbitmap_suspend_tiCVE-2026-45955 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1
In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: fix percpu_ref not resurrected on suspend timeout When llbitmap_suspend_timeout() times out waiting for percpu_ref to become zero, it returns -ETIMEDOUT without resurrecting the percpu_ref. The caller (md_llbitmap_daemon_fn) then continues to the next page without calling llbitmap_resume(), leaving the percpu_ref in a killed state permanently. Fix this by resurrecting the percpu_ref before returning the error, ensuring the page control structure remains usable for subsequent operations.
- 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
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix IO hang with degraded array with llbitmap When llbitmap bit state is still uCVE-2026-45953 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix IO hang with degraded array with llbitmap When llbitmap bit state is still unwritten, any new write should force rcw, as bitmap_ops->blocks_synced() is checked in handle_stripe_dirtying(). However, later the same check is missing in need_this_block(), causing stripe to deadloop during handling because handle_stripe() will decide to go to handle_stripe_fill(), meanwhile need_this_block() always return 0 and nothing is handled.
- 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
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed durinCVE-2026-45942 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process
- 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
May 6, 2026In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs iCVE-2026-43163 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 4.7
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
- 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
May 6, 2026In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: CGX: fix bitmap leaks The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and txCVE-2026-43157 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: CGX: fix bitmap leaks The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap) are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit(). Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probe Free both bitmaps during teardown.
- 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
Mar 2, 2026In dumpBitmapsProto of ActivityManagerService.java, there is a possible way for an app to access private information due to a missing permission check.CVE-2026-0047 · Computers, phones & browsers · Google · reported by security@android.comHigh 8.4
In dumpBitmapsProto of ActivityManagerService.java, there is a possible way for an app to access private information due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
- Product
- Android
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Dec 24, 2025In the Linux kernel, the following vulnerability has been resolved: exfat: fix divide-by-zero in exfat_allocate_bitmap The variable max_ra_count can be 0 in eCVE-2025-68350 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: exfat: fix divide-by-zero in exfat_allocate_bitmap The variable max_ra_count can be 0 in exfat_allocate_bitmap(), which causes a divide-by-zero error in the subsequent modulo operation (i % max_ra_count), leading to a system crash. When max_ra_count is 0, it means that readahead is not used. This patch load the bitmap without readahead.
- 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
Dec 10, 2025ImageMagick is a software suite to create, edit, compose, or convert bitmap images.CVE-2025-66628 · Other software · ImageMagick · reported by GitHubHigh 7.5
ImageMagick is a software suite to create, edit, compose, or convert bitmap images. In versions 7.1.2-9 and prior, the TIM (PSX TIM) image parser contains a critical integer overflow vulnerability in its ReadTIMImage function (coders/tim.c). The code reads width and height (16-bit values) from the file header and calculates image_size = 2 * width * height without checking for overflow. On 32-bit systems (or where size_t is 32-bit), this calculation can overflow if width and height are large (e.g., 65535), wrapping around to a small value. This results in a small heap allocation via AcquireQuantumMemory and later operations relying on the dimensions can trigger an out of bounds read. This issue is fixed in version 7.1.2-10.
- Product
- ImageMagick
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
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.