Buffer Overflow

Out-of-bounds write in bzip2's bzip2recover utility allows a local attacker to supply a specially crafted file that triggers an off-by-one error, corrupting a global buffer and crashing the process. Per the CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N), the attack requires no privileges and no user interaction beyond the utility being invoked against a malicious file. Impact is strictly denial of service against the bzip2recover process - no confidentiality or integrity exposure - and the CVSS 4.0 score of 5.1 (Medium) reflects this constrained scope. No public exploit or active exploitation has been identified at time of analysis.

CryptX versions before 0.088_001 for Perl have a stack buffer overflow in four AEAD decrypt_verify helpers. The gcm_decrypt_verify, ccm_decrypt_verify, chacha20poly1305_decrypt_verify and eax_decrypt_verify XS routines copied the caller-supplied authentication tag into a fixed 144-byte stack buffer (MAXBLOCKSIZE) without checking the supplied length. A longer tag overwrites the stack past the buffer. Version 0.088 added the clamp to gcm_decrypt_verify, and 0.088_001 added it to the other three. Any caller of an affected helper that forwards an attacker-controlled tag longer than the buffer can trigger the overflow.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Avoid overflow on msg bound check As pointed out by SDL, the previous condition may be vulnerable to overflow. (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Avoid overflow on msg bound check As pointed out by SDL, the previous condition may be vulnerable to overflow. (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)

In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().

In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)

In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message

In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show() Sashiko noticed an out-of-bounds read [1]. In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names). Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended. Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count. Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.

In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read.

In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)

In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.

In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in smb2_compound_op() If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, check_wsl_eas() returns success without validating that the entire OutputBufferLength fits within iov_len. Then smb2_compound_op() does: memcpy(idata->wsl.eas, data[0], size[0]); Where size[0] is OutputBufferLength. If iov_len is smaller than size[0], memcpy can read beyond the end of the rsp_iov allocation and leak adjacent kernel heap memory.

In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtk: validate WMT event SKB length before struct access btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom. Use skb_pull_data() to validate and advance past the base WMT event header. For the FUNC_CTRL case, pull the additional status field bytes before accessing them.

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and "rdma link add"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.

In the Linux kernel, the following vulnerability has been resolved: dm-verity-fec: fix reading parity bytes split across blocks (take 3) fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks. This assumption is false. Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes. Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed. On the 16th call (i=15), the alignment will be 4080 bytes into the first block. Only 16 bytes remain in that block, but 17 parity bytes will be needed. The code reads out-of-bounds from the parity block buffer. Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots *and* when the maximum number of buffers couldn't be allocated due to low memory. For example with block_size=4096 only the following cases are affected: fec_roots=17: nbufs in [1, 3, 5, 15] fec_roots=19: nbufs in [1, 229] fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195] fec_roots=23: nbufs in [1, 89] Regardless, fix it by refactoring how the parity blocks are read.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length.

In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.

In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.

Keycloak's ClientRegistrationAuth component can be crashed by a remote unauthenticated attacker through a specially crafted POST request bearing a malformed 'Authorization: Bearer' header, triggering an unhandled ArrayIndexOutOfBoundsException and returning HTTP 500 to all subsequent callers of the affected endpoint. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms zero prerequisites for exploitation beyond network reachability, making any publicly exposed Keycloak client registration endpoint a viable target. No public exploit has been identified at time of analysis and no EPSS data was supplied, but the trivial attack mechanics mean no specialized tooling is required to reproduce the denial of service.

Out-of-bounds write in Samsung's Escargot JavaScript engine allows attacker-supplied scripts to corrupt memory through the ArrayBuffer.prototype.transfer() built-in, with high confidentiality, integrity, and availability impact (CVSS 8.8). The flaw stems from a missing length-bounds check when transferring an ArrayBuffer to a new byte length, enabling writes past the allocated buffer that can lead to remote code execution if a victim runs the malicious script. No public exploit has been identified at time of analysis, and no EPSS or CISA KEV data was provided.

Heap buffer overflow in pam_usb prior to 0.9.1 allows a local attacker with high privileges to corrupt heap memory on 32-bit Linux platforms (armv7l, i686) by supplying a crafted configuration file with an excessive device count. The root cause is an unchecked integer multiplication in src/conf.c where n_devices * sizeof(t_pusb_device) wraps around size_t on 32-bit targets, causing xmalloc() to receive a drastically undersized allocation that is silently accepted, enabling out-of-bounds writes into heap memory. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog; however, successful exploitation yields full confidentiality, integrity, and availability impact on the affected host.

Remote code execution in Gladinet Triofox is possible through a stack-based buffer overflow in WOSDefaultHttpModule.dll, which fails to bounds-check overly long URL paths beginning with /woshome. Because the flaw is reachable over the network with no authentication and no user interaction (CVSS 9.8), an attacker who can reach the Triofox web service can corrupt the stack and potentially execute arbitrary code in the context of the web module. No public exploit has been identified at the time of analysis, and the issue was reported by Tenable (TRA-2026-45).

Remote code execution in Gladinet Triofox is possible through a stack-based buffer overflow in the WOSDeviceDropFolder.dll component, which mishandles overly long URL paths that begin with /resources. The CVSS 9.8 vector indicates an unauthenticated, network-reachable flaw requiring no user interaction, meaning any attacker who can reach the Triofox web service can corrupt the stack and potentially execute arbitrary code. The issue was reported by Tenable (TRA-2026-45); no public exploit identified at time of analysis and no EPSS score was provided in the source data.

Heap-based buffer overflow in TeamSpeak 3 Server's ECC Key Parser allows remote unauthenticated attackers to crash the server, causing a denial of service against all versions up to and including 3.13.7. The vulnerability was discovered and disclosed by modzero security research (advisory mz-26-01-teamspeak) with a coordinated vendor response resulting in TeamSpeak security advisory TS-SA-2026-001. A proof-of-concept exploit exists per SSVC data, and the attack is automatable, meaning exploitation can be scripted at scale against exposed TeamSpeak server instances. No public exploit identified as confirmed actively exploited in the wild (not listed in CISA KEV at time of analysis).

Use-after-free in TeamSpeak 3 Server versions 3.13.0 through 3.13.7 allows a low-privileged remote attacker to corrupt server memory via the process_resend_queue function within Connection State Management, resulting in limited integrity and availability impact. Discovered and disclosed by modzero.com (advisory MZ-26-01) and acknowledged by TeamSpeak via official security advisory TS-SA-2026-001, the vendor has released version 3.13.8 as the fix. No public exploit code exists and no active exploitation has been identified at time of analysis.

Out-of-bounds write in LibVNCClient (shipped in the LibVNCServer project, versions 0.9.15 and earlier) lets a malicious or compromised VNC server corrupt memory in any client that connects to it. The Tight encoding decoder's Gradient filter uses fixed 2048-pixel scratch buffers but never validates the server-supplied rectangle width, so a crafted FramebufferUpdate with a width above 2048 overruns those buffers, threatening confidentiality, integrity, and availability (CVSS 8.8). There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the issue is fixed by upstream commit 5b270544.

Heap buffer overflow in libjxl 0.12.0 lets remote attackers corrupt heap memory by feeding a crafted PBM/PNM image to the jxl::extras::DecodeImagePNM routine, which writes decoded rows into an output buffer without first checking that the buffer is large enough for the header-declared dimensions. The CVSS vector (AV:N/AC:L/PR:N/UI:N) describes unauthenticated, low-complexity exploitation with no user interaction, and CISA's SSVC framework rates it automatable with partial technical impact. Publicly available exploit code exists, though it is not listed in CISA KEV and no public exploit has been tied to active exploitation.

Arbitrary code execution in IBM Aspera High-Speed Transfer Server and Endpoint (versions 3.7.4 through 4.4.7 Fix Pack 1) arises from a stack-based buffer overflow in the asperahttpd component. An authenticated user with network access can corrupt memory in this HTTP handling component to run code in the context of the service, fully compromising confidentiality, integrity, and availability (CVSS 8.8). No public exploit has been identified at time of analysis, and the CVE is not listed in CISA KEV; EPSS data was not provided.

Remote code execution and authentication bypass are possible in IBM Aspera High-Speed Transfer Server and High-Speed Transfer Endpoint (versions 3.7.4 through 4.4.7 Fix Pack 1) through a heap-based buffer overflow in the asperahttpd component. An unauthenticated network attacker can corrupt memory to crash the service (denial of service) and, in the worst case, hijack execution flow to run arbitrary code or bypass authentication. There is no public exploit identified at time of analysis and SSVC lists exploitation as none, but the CVSS 9.8 rating and 'Automatable: yes' assessment mark this as a high-priority patching target.

Out-of-bounds read in libusb's parse_iad_array() function (descriptor.c) affects all releases before 1.0.30, enabling local attackers in virtualized environments with USB passthrough to crash libusb-dependent processes via a crafted USB descriptor. The off-by-one error causes the bounds check to evaluate against the original total buffer size rather than the remaining unparsed size, allowing a one-byte read past the end of the malloc allocation when a descriptor's bLength is set to exactly (total_size - 1). No public exploit code exists and the vulnerability is absent from CISA KEV; a vendor-released patch is confirmed in v1.0.30.

In the Linux kernel, the following vulnerability has been resolved: ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration.

In the Linux kernel, the following vulnerability has been resolved: crypto: acomp - fix wrong pointer stored by acomp_save_req() acomp_save_req() stores &req->chain in req->base.data. When acomp_reqchain_done() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acomp_req. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption. The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomp_request_set_src_dma()). This combination causes crypto_acomp_compress() to enter the acomp_do_req_chain() path, which sets acomp_reqchain_done() as the completion callback via acomp_save_req(). With KASAN enabled, this manifests as a general protection fault in acomp_reqchain_done(): general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acomp_reqchain_done+0x15b/0x4e0 Call Trace: <IRQ> qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 </IRQ> Fix this by storing the request itself in req->base.data instead of &req->chain, so that acomp_reqchain_done() receives the correct pointer. Simplify acomp_restore_req() accordingly to access req->chain directly.

In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com

In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.

In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).

In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix string overrun due to missing termination When booting Ubuntu 26.04 with Linux 7.0-rc4 on an ARM64 Qualcomm Snapdragon X1 we see a string buffer overrun: BUG: KASAN: slab-out-of-bounds in aa_dfa_match (security/apparmor/match.c:535) Read of size 1 at addr ffff0008901cc000 by task snap-update-ns/2120 CPU: 5 UID: 60578 PID: 2120 Comm: snap-update-ns Not tainted 7.0.0-rc4+ #22 PREEMPTLAZY Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025 Call trace: show_stack (arch/arm64/kernel/stacktrace.c:501) (C) dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) __asan_report_load1_noabort (mm/kasan/report_generic.c:378) aa_dfa_match (security/apparmor/match.c:535) match_mnt_path_str (security/apparmor/mount.c:244 security/apparmor/mount.c:336) match_mnt (security/apparmor/mount.c:371) aa_bind_mount (security/apparmor/mount.c:447 (discriminator 4)) apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1)) security_sb_mount (security/security.c:1062 (discriminator 31)) path_mount (fs/namespace.c:4101) __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338) invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2)) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744) el0t_64_sync (arch/arm64/kernel/entry.S:596) Allocated by task 2120: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/arm64/include/asm/current.h:19 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_alloc_info (mm/kasan/generic.c:571) __kasan_kmalloc (mm/kasan/common.c:419) __kmalloc_noprof (./include/linux/kasan.h:263 mm/slub.c:5260 mm/slub.c:5272) aa_get_buffer (security/apparmor/lsm.c:2201) aa_bind_mount (security/apparmor/mount.c:442) apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1)) security_sb_mount (security/security.c:1062 (discriminator 31)) path_mount (fs/namespace.c:4101) __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338) invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2)) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744) el0t_64_sync (arch/arm64/kernel/entry.S:596) The buggy address belongs to the object at ffff0008901ca000 which belongs to the cache kmalloc-rnd-06-8k of size 8192 The buggy address is located 0 bytes to the right of allocated 8192-byte region [ffff0008901ca000, ffff0008901cc000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9101c8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:-1 pincount:0 flags: 0x8000000000000040(head|zone=2) page_type: f5(slab) raw: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70 raw: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000 head: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70 head: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000 head: 8000000000000003 fffffdffe2407201 fffffdffffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff0008901cbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.

In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.

In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.

In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]

In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.

{ void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue: ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.

In the Linux kernel, the following vulnerability has been resolved: mtd: intel-dg: Fix accessing regions before setting nregions The regions array is counted by nregions, but it's set only after accessing it: [] UBSAN: array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c:750:15 [] index 0 is out of range for type '<unknown> [*]' Fix it by also fixing an undesired behavior: the loop silently ignores ENOMEM and continues setting the other entries.

{ 436 int r; 437 438 if (!kfd_dbg_owns_dev_watch_id(pdd, watch_id)) kfd_dbg_owns_dev_watch_id() doesn't check for negative values so if watch_id is larger than INT_MAX it leads to a buffer overflow. (Negative shifts are undefined). 439 return -EINVAL; 440 441 if (!pdd->dev->kfd->shared_resources.enable_mes) { 442 r = debug_lock_and_unmap(pdd->dev->dqm); 443 if (r) 444 return r; 445 } 446 447 amdgpu_gfx_off_ctrl(pdd->dev->adev, false); --> 448 pdd->watch_points[watch_id] = pdd->dev->kfd2kgd->clear_address_watch( 449 pdd->dev->adev, 450 watch_id); v2: (as per, Jonathan Kim) - Add early watch_id >= MAX_WATCH_ADDRESSES validation in the set path to match the clear path. - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id().

In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges() amdgpu_discovery_get_nps_info() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption. Use kvfree() to safely handle both kmalloc and vmalloc allocations. Compile tested only. Issue found using a prototype static analysis tool and code review.

Heap buffer overflow in Tasmota IoT firmware (through version 15.3.0.3) lets a remote attacker corrupt heap memory by manipulating the Content-Length of a JPEG stream processed by the fetch_jpg() routine in the scripter driver. Because the length is stored in a 16-bit integer, values above 65535 wrap to a small number, so the firmware allocates an undersized buffer and then reads the full, larger payload into it. Publicly available exploit code exists (a dedicated GitHub repository), CISA's SSVC framework rates exploitation as proof-of-concept and automatable, but the issue is not in CISA KEV and no public active exploitation is identified.

Remote code execution in Tasmota firmware (v15.3.0.3 and all earlier releases) stems from an unbounded strcpy() into the fixed 40-byte jpg_task.boundary[40] buffer inside fetch_jpg() in the Scripter driver (xdrv_10_scripter.ino). A network attacker able to reach the device and trigger this code path can overflow the buffer and, per the vendor description, execute arbitrary code on the ESP-based device. Publicly available exploit code exists (a CVE-named GitHub repository), and CISA's SSVC framework rates exploitation as POC with the attack automatable; no active exploitation is confirmed.

Remote code execution in Tasmota firmware version 15.3.0.3 and earlier allows remote unauthenticated attackers to trigger a stack-based buffer overflow in the fetch_jpg() function of the xdrv_10_scripter.ino scripting driver. The flaw is exposed over the network with low complexity and no privileges required (CVSS 7.3 AV:N/AC:L/PR:N/UI:N), and a public proof-of-concept repository has been registered, though no public exploit code was identified in the references at time of analysis. EPSS probability is very low (0.05%, 15th percentile) and the issue is not listed in CISA KEV.

NULL pointer dereference in libusb's USB descriptor parser allows any attacker who can supply a crafted configuration descriptor to crash any application that uses libusb for USB device enumeration. Affected versions are all libusb releases before 1.0.30; the flaw resides in parse_interface() within descriptor.c and is reachable through the public APIs libusb_get_active_config_descriptor and libusb_get_config_descriptor. No public exploit code is identified at time of analysis and this CVE does not appear in the CISA KEV catalog, but the availability impact is confirmed high (CVSS 4.0 VA:H) and regression corpus files in the fix commit demonstrate reliable crash reproduction.

In the Linux kernel, the following vulnerability has been resolved: ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec() KASAN reported a stack-out-of-bounds access in ima_appraise_measurement from is_bprm_creds_for_exec: BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: ima_appraise_measurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash' This is caused by using container_of on the *file pointer. This offset calculation is what triggers the stack-out-of-bounds error. In order to fix this, pass in a bprm_is_check boolean which can be set depending on how process_measurement is called. If the caller has a linux_binprm pointer and the function is BPRM_CHECK we can determine is_check and set it then. Otherwise set it to false.

In the Linux kernel, the following vulnerability has been resolved: drm/display/dp_mst: Add protection against 0 vcpi When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: <TASK> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.

In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. "0:1:2" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf("%d"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: <TASK> bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) </TASK> CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.

Remote code execution in Synology BeeStation OS versions before 1.3.2-65648 stems from a classic buffer overflow in the AdminCenter component, the device's web-based management interface. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) indicates a network-reachable flaw exploitable by unauthenticated attackers with low complexity and no user interaction, yielding full compromise of confidentiality, integrity, and availability (9.8 Critical). There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV, but the unauthenticated network-RCE profile on a consumer NAS device makes this a high-priority patch target.

Stack-based buffer overflow in the UTT HiPER 1250GW router (firmware up to 3.2.7-210907-180535) lets a network-adjacent authenticated user corrupt memory by supplying an oversized 'Profile' argument to the /goform/formGroupConfig endpoint of the Web Management Interface. The CVSS 4.0 score is 7.4, and publicly available exploit code exists, though the EPSS probability is very low (0.04%, 13th percentile) and it is not on the CISA KEV list. Successful exploitation can crash the device or potentially achieve arbitrary code execution on the router's management plane.

Stack-based buffer overflow in the web management interface of the UTT HiPER 1250GW router (firmware through 3.2.7-210907-180535) lets a remote, low-privileged attacker corrupt memory by submitting an oversized Profile value to the /goform/formConfigFastDirectionW handler, which passes it to an unbounded strcpy. The CVSS 4.0 vector rates confidentiality, integrity, and availability impact as High, consistent with potential code execution or device crash. Publicly available exploit code exists per the VulDB submission, though EPSS is very low (0.04%, 13th percentile) and there is no public exploit identified as actively exploited.

Stack-based buffer overflow in the UTT HiPER 1200GW router's Web Management Interface lets an authenticated, network-adjacent attacker corrupt memory by submitting oversized values to the PPTP client configuration handler (/goform/formPptpClientConfig), affecting firmware up to 2.5.3-170306. A successful overflow can crash the device or potentially achieve code execution on the embedded gateway, with high confidentiality, integrity, and availability impact on the device itself. Publicly available exploit code exists (CVSS 4.0 base 7.4), but the EPSS score is very low at 0.04% (13th percentile) and the issue is not listed in CISA KEV.

Stack buffer overflow in the UTT HiPER 1200GW router (firmware up to 2.5.3-170306) lets a remote, low-privileged user crash the device or potentially execute arbitrary code by submitting oversized sysAdmUser or sysAdmPass values to the /goform/setSysAdm endpoint of the Web Management Interface. The flaw stems from an unbounded strcpy call, and publicly available exploit code exists, though EPSS rates near-term mass exploitation as very low (0.04%). No CISA KEV listing or vendor patch has been identified.

Arbitrary code execution in GDAL 3.1.0 through 3.13.0 is reachable through the netCDF driver, where scanForGeometryContainers (frmts/netcdf/netcdfsg.cpp) copies a CF-convention geometry attribute into a fixed-size stack buffer without checking its length. Any service or workflow that feeds attacker-supplied NetCDF files to GDAL can be coerced into overflowing the stack and running attacker code in the process context. No public exploit is identified at time of analysis and EPSS is just 0.01% (3rd percentile), yet the issue carries a CVSS of 7.4 because the outcome is full remote code execution on the host.

Out-of-bounds read in Apple macOS (all versions prior to macOS Tahoe 26) allows a locally authenticated, low-privileged application to trigger unexpected system termination, constituting a local denial-of-service condition. The root cause is insufficient bounds checking in a macOS component, addressed by Apple in macOS Tahoe 26. No public exploit code exists and this vulnerability is not listed in CISA KEV, though a vendor-confirmed patch is available.

Memory corruption via an off-by-one error in GnuTLS PKCS#12 bag element handling exposes any application using GnuTLS to remote unauthenticated denial of service - and potentially unspecified further impact - when a crafted PKCS#12 structure is parsed. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms exploitation requires no authentication, no user interaction, and no elevated complexity, making internet-exposed services that parse client-supplied PKCS#12 inputs the primary risk surface. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog at time of analysis.

Information disclosure and denial of service in GnuTLS (libgnutls) let a remote, unauthenticated attacker trigger a heap overread against TLS servers that perform legacy RSA key exchange using a private key backed by a PKCS#11 token. By sending an abnormally short premaster secret, the attacker causes the library to read beyond an allocated buffer (CWE-1284), which can leak a small amount of adjacent heap memory and, per the CVSS vector, more strongly impacts availability (A:H). No public exploit has been identified at time of analysis and the issue is not in CISA KEV; EPSS and SSVC data were not provided.

Symlink-based path traversal in the Perl module Archive::Tar before version 3.08 allows a malicious tar archive to write or point files outside the intended extraction directory. When an application extracts an attacker-supplied archive, symlink entries whose targets are absolute paths or contain '..' traversal sequences are followed without validation, letting an attacker place links that resolve to arbitrary filesystem locations. EPSS is very low (0.02%, 6th percentile) and there is no public exploit identified at time of analysis, but the issue is rated CVSS 9.1 because Archive::Tar is widely embedded in automated server-side processing of untrusted archives.

Arbitrary file modification in the Perl Archive::Tar module before version 3.08 allows a malicious tar archive to create hardlinks pointing outside the extraction directory. Any application or service that extracts attacker-supplied tarballs is affected: because extraction chmods the shared inode of a hardlink, an attacker can alter permissions of sensitive files outside the intended target path. EPSS is very low (0.02%, 5th percentile) and there is no public exploit identified at time of analysis; it is not listed in CISA KEV.

Heap buffer overflow in FastNetMon Community Edition through 1.2.9 originates from a CWE-190 integer overflow in the BGP AS_PATH attribute encoder (IPv4UnicastAnnounce::get_attributes() in src/bgp_protocol.hpp). When an AS_PATH carries more than 63 ASNs, the computed attribute length is silently truncated into a uint8_t field used for buffer sizing while the full data is still written, corrupting the heap. The CVSS 9.8 score implies remote unauthenticated code execution, though the flaw lives in FastNetMon's outbound BGP announcement encoder; no public exploit is identified at time of analysis and no EPSS or KEV data was supplied.

Remote code execution in FastNetMon Community Edition through 1.2.9 stems from an off-by-one heap write in the pervasively-used dynamic_binary_buffer_t class, reachable by anyone who can send NetFlow, sFlow, IPFIX, or BGP traffic to the DDoS-detection appliance. Because the flawed buffer is exercised during BGP encoding/decoding, NetFlow template parsing, and Flow Spec NLRI construction, an unauthenticated network attacker can corrupt adjacent heap metadata and potentially execute arbitrary code. The flaw carries a critical CVSS 9.8 (AV:N/AC:L/PR:N/UI:N), but no public exploit is identified at time of analysis and it is not listed in CISA KEV.

Buffer overflow in FastNetMon Community Edition through 1.2.9 allows a local attacker with no privileges to crash the FastNetMon process, disabling DDoS detection and network monitoring capabilities. The vulnerability is specifically tied to a sprintf-based overflow in the ExaBGP integration component, as documented in the Lorikeetsecurity advisory. This is one of at least three distinct buffer overflow vulnerabilities (alongside CVE-2026-48686 and CVE-2026-48689) identified in the same product version, suggesting a broader audit surfaced a class of unsafe string-handling bugs. No public exploit identified at time of analysis, and the impact is limited to availability (denial of service) with no confidentiality or integrity exposure.

Heap-based buffer overflow in Perl interpreters up to and including 5.43.10 on 32-bit builds lets a caller that compiles an attacker-controlled regular expression corrupt heap memory at regex compile time, with potential for code execution. The flaw stems from an integer overflow in Perl_study_chunk when optimizing a repeated fixed substring, and is rated CVSS 9.8 by NVD. EPSS is very low (0.02%, 5th percentile) and there is no public exploit identified at time of analysis; the issue is limited to 32-bit Perl builds and applications that feed untrusted input into regex compilation.

Heap-based buffer overflow in Ettercap's GG protocol dissector (versions up to 0.8.3) allows remote attackers to potentially achieve limited confidentiality, integrity, and availability compromise through crafted network traffic. The vulnerability exists in the ec_gg.c dissector when processing Gadu-Gadu instant messaging protocol packets. Publicly available exploit code exists (GitHub issue #1306), and vendor has released patch version 0.8.4 (commit feeae6fa). Despite network attack vector, exploitation difficulty is high (AC:H) with low EPSS risk, suggesting specialized targeting rather than mass exploitation.

Buffer overflow in Edimax EW-7438RPn Wi-Fi range extender firmware 1.28a enables authenticated remote attackers to execute arbitrary code via malformed POST requests to the wireless encryption configuration endpoint. The vulnerability requires low-privilege authentication and has publicly available exploit code. No vendor response or patch has been provided despite early disclosure attempts.

Stack-based buffer overflow in Edimax EW-7438RPn WiFi range extender firmware up to version 1.31 enables authenticated remote attackers to execute arbitrary code by sending malicious input to the /goform/mp endpoint in the web server component. Public exploit code exists on GitHub, though the vulnerability is not listed in CISA KEV. The vendor failed to respond to responsible disclosure attempts, leaving devices unpatched.

Buffer overflow in Edimax EW-7438RPn WiFi range extender firmware up to version 1.31 enables authenticated remote attackers to execute arbitrary code via crafted POST requests to the wireless table management interface. The vulnerability affects the formWirelessTbl function when processing the submit-url parameter, with publicly available exploit code on GitHub demonstrating the attack method.

Buffer overflow in Edimax EW-7438RPn WiFi range extender firmware versions up to 1.31 enables authenticated remote attackers to execute arbitrary code by sending malformed parameters to the device configuration interface. The vulnerability affects the formWizSurvey function in /goform/formWizSurvey when processing ssid, manualssid, ip, mask, or gateway parameters, with publicly available exploit code existing on GitHub.

Stack-based buffer overflow in Edimax EW-7438RPn WiFi range extender firmware up to version 1.31 allows authenticated remote attackers to crash or execute code on the device by sending malicious input to the WPS configuration interface. The vulnerability occurs when processing the pinCode or wlan-url parameters in /goform/formWpsStart, with publicly available exploit code on GitHub demonstrating the attack.

Memory corruption in OMEC Project AMF (Access and Mobility Management Function) versions up to 2.1.1 allows authenticated remote attackers to corrupt memory by sending malformed NGReset messages to the 5G core network component. The vulnerability stems from insufficient validation of PLMN ID strings in SUCI (Subscription Concealed Identifier) processing within the NGReset message handler. Public exploit code exists (GitHub issue #678), and vendor patch is available (PR #666 upgrading to version 2.2.0). EPSS data not available but exploit code publication increases real-world exploitation likelihood for targeted attacks against 5G core infrastructure.

Memory corruption in the omec-project AMF (Access and Mobility Management Function) NGSetupRequest Handler allows network-adjacent authenticated attackers to corrupt process memory via crafted NGAP messages or malformed SUCI values, affecting confidentiality, integrity, and availability. The vulnerability stems from missing nil-pointer guards in the NGAP dispatcher and absent input validation when parsing Subscription Concealed Identifiers (SUCI) during UE registration and identity response flows. Exploit code has been publicly disclosed (GitHub issue #679), and no public exploit identified at time of analysis confirms active KEV exploitation, though the CVSS temporal vector E:P confirms proof-of-concept availability.

Memory corruption in omec-project AMF versions up to 2.1.1 exposes 5G core network infrastructure to remote exploitation via crafted NGAP PDUSessionResourceModifyIndication messages, allowing low-privileged attackers to achieve partial confidentiality, integrity, and availability impact on the Access and Mobility Management Function. A publicly available exploit exists (confirmed by CVSS E:P and GitHub issue #681), and an official vendor patch has been released in version 2.2.0 via PR #666. No CISA KEV listing was identified at time of analysis, so active widespread exploitation is not confirmed.

Memory corruption in omec-project AMF (Access and Mobility Management Function) through version 2.1.1 allows authenticated remote attackers to corrupt memory by sending crafted NGAP or NAS messages targeting the PathSwitchRequest handler and related message processing paths. The CVSS vector (AV:N/AC:L/PR:L/UI:N/C:L/I:L/A:L) indicates low-complexity network exploitation requiring only low-privilege credentials, with partial impacts across confidentiality, integrity, and availability. Publicly available exploit code exists (confirmed by GitHub issue #680 and the E:P temporal modifier); no active exploitation is confirmed in CISA KEV.

Buffer overflow in the Edimax BR-6428NS 1.10 router's web management interface allows authenticated remote attackers to corrupt memory by submitting a crafted vapurl parameter to the formWirelessTbl POST handler at /goform/formWirelessTbl. Publicly available exploit code exists (released via VulDB and a Notion writeup), and the vendor has not responded to coordinated disclosure attempts. The flaw is not currently listed in CISA KEV, but the combination of public PoC, low attack complexity, and an unpatched/unresponsive vendor makes this a tangible risk for any exposed device.

Stack buffer overflow in the Edimax BR-6428NS 1.10 wireless router allows authenticated remote attackers to corrupt memory by sending an overlong pppUserName parameter to the /goform/formWanTcpipSetup endpoint. Publicly available exploit code exists, and the vendor failed to respond to the coordinated disclosure attempt, leaving devices without an official fix. With a CVSS of 8.8 and full CIA impact, successful exploitation can result in arbitrary code execution or device takeover on the embedded router.

Out-of-bounds read in libheif versions 1.21.2 and prior crashes any application that parses attacker-controlled HEIF sequence files, resulting in denial of service. The defect lives in the SampleAuxInfoReader constructor, which enters its processing loop when saiz.sample_count > 0 even though stco.entry_count == 0 left the chunks vector empty; dereferencing chunks[0] then triggers the crash. No public exploit code has been identified at time of analysis, but the attack requires only that a user open or process a specially crafted HEIF file, making it relevant wherever libheif is embedded in image-handling applications (browsers, media libraries, operating-system image stacks). Vendor-released patch v1.22.0 is available.

Integer overflow in NewNTUnicodeString within the Go extended syscall package for Windows allows a local low-privileged attacker to silently inject a truncated NTUnicodeString into applications that expect validation failures on oversized input. Affected is golang.org/x/sys/windows before version 0.44.0. Because the function returns a truncated result rather than an error, consuming code may proceed with a malformed string, potentially bypassing length-based security checks or causing downstream logic errors - no public exploit has been identified at time of analysis and EPSS exploitation probability is 0.02%.

Heap buffer overflow in NGINX Plus and NGINX Open Source ngx_http_rewrite_module allows unauthenticated remote attackers to crash worker processes and potentially achieve code execution via crafted HTTP requests targeting servers using rewrite directives with overlapping PCRE captures. The flaw affects a core HTTP module shipped in default builds, making widespread exposure plausible wherever vulnerable rewrite rules are configured, though exploitation requires specific configuration prerequisites and ASLR bypass for full RCE. No public exploit identified at time of analysis and the issue is not listed in CISA KEV.

vifm is vulnerable to a heap buffer overflow during the history merge process when saving the state file (vifminfo.json). This flaw occurs because the application lacks a runtime check on the length of history entries in release builds, potentially allowing a crafted long path or command in the history to cause memory corruption or application crashes. Releases from 0.12.1 to 0.14.3 (including) are considered vulnerable. This issue was fixed in commit 23063c7