Buffer Overflow
Monthly
Stack buffer overflow in PJSIP's (pjproject) telnet CLI front-end allows unauthenticated network attackers to crash applications that have explicitly enabled the telnet administration interface. The functions send_err_arg() and send_ambi_arg() in cli_telnet.c wrote an attacker-influenced number of bytes into a fixed 256-byte stack buffer without bounds checking, with the error-position offset derived directly from parsed command input. The vulnerability is limited to application termination (DoS); no public exploit code has been identified at time of analysis, and the upstream fix is available as commit 4472a31.
Stack-based buffer overflow in PJSIP pjproject's telnet CLI front-end allows remote, unauthenticated attackers to crash the affected application by sending history-recall input sequences (arrow keys) to the `handle_up_down()` function in `cli_telnet.c`. The accumulated redraw data - comprising cursor position, current buffer length, and recalled history entry length - can exceed the fixed-size `PJ_CLI_MAX_CMDBUF` stack buffer, leading to application termination. Exploitation requires the telnet CLI front-end to be explicitly enabled; applications that do not enable this feature are entirely unaffected, and no public exploit or KEV listing has been identified at time of analysis.
Off-by-one buffer overflow in pjproject's SIP message serialization function allows a remote peer to trigger a single-byte out-of-bounds write by sending crafted SIP requests to a proxy, SBC, or B2BUA that parses and re-serializes messages using the PJSIP library. The vulnerable function `pjsip_generic_array_hdr_print()` in `sip_msg.c` omitted bounds checking before writing the colon and space characters that follow generic array header names (Allow, Require, Supported, Unsupported), resulting in CWE-193 off-by-one writes at exact buffer boundaries. No public exploit has been identified at time of analysis; the vendor explicitly states that code execution and information disclosure have not been demonstrated, and pool-based allocator slack typically absorbs the errant byte harmlessly.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: use check_add_overflow for shader size+offset bound vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size.
In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the attribute-list entry in ntfs_read_inode_mount() The $MFT attribute-list walk in ntfs_read_inode_mount() validates each entry only with "(u8 *)al_entry + 6 > al_end" and "(u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end", but then reads al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference (offset 16) -- fields beyond the 6 bytes proven in range. al_entry->length is attacker-controlled and only required non-zero, so a short entry (e.g. length 8) placed at the tail passes both checks while the lowest_vcn / mft_reference reads fall past al_end. al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding usually absorbs the over-read -- but when attr_list_size is a multiple of SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an out-of-bounds read at mount time. Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing it, matching the bound the other attribute-list walks now use. The validator already requires the length to cover the fixed header, which makes the separate "!al_entry->length" check redundant, so drop it too.
Stack-based buffer overflow in IBM i 7.3 through 7.6 allows remote authenticated attackers to cause a denial of service by sending specially crafted network input that exceeds a stack-allocated buffer in a network-accessible component. The vulnerability is gated behind low-privilege authentication (PR:L) and carries no confidentiality or integrity impact, as IBM's advisory scores it CVSS 4.3 with A:L. No public exploit code or active exploitation has been identified; a vendor-released patch is available via the IBM support portal.
Stack-based buffer overflow in IBM i 7.3 through 7.6 allows an authenticated local attacker to crash the system, producing a denial of service with no confidentiality or integrity impact. The flaw is classified as CWE-121 and is limited in severity by both the access prerequisites and the bounded availability-only outcome. A vendor patch is available via IBM's support portal, and no public exploit code has been identified at time of analysis.
Denial of service on IBM i versions 7.3 through 7.6 is achievable by exploiting an off-by-one write in the LPD (Line Printer Daemon) queue name parser, corrupting adjacent memory and crashing the affected service. The vendor description specifies a local authenticated attacker as the threat actor, yet IBM's own submitted CVSS vector (AV:N/AC:L/PR:N/UI:N) characterizes this as an unauthenticated network-reachable flaw - a direct contradiction that materially affects risk prioritization. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 </TASK> Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---
In the Linux kernel, the following vulnerability has been resolved: tls: device: fix out-of-bounds write in tls_append_frag() Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK> and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: <TASK> worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK>
In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.
In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.
In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - bound the akcipher result length virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: gb_len = atr_req->length - sizeof(struct st21nfca_atr_req); ... memcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.
In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.
In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec() io_vec_fill_bvec() computes the folio size with a plain int 1: unsigned long folio_size = 1 << imu->folio_shift; imu->folio_shift is unsigned int and comes from folio_shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio_shift shift in this file already uses 1UL. The result is that the segment estimate and the fill loop disagree. io_estimate_bvec_size() sizes the bvec array with the real shift: max_segs += (iov[i].iov_len >> shift) + 2; so a 1M iovec on a 16G folio is charged 2 segments, while io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4 bytes and writes res_bvec[bvec_idx] a quarter of a million times, past the end of the array it was given. src_bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate_fixed_range() only checks that the range is inside the registered buffer and does not bound the segment count. Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registers that size, and likewise on powerpc. x86_64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected. Use 1UL, as the rest of the file does.
In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.
In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.
In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes tlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 ("net: nfc: nci: Fix parameter validation for packet data"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().
In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a "size < 1" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: hid_dump_input(field->report->device, field->usage + offset, value); if (offset >= field->report_count) { hid_err(...); return -1; } Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs "offset (1) exceeds report_count (1)" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Use the same sizeof(struct joycon_input_report) bound here.
Out-of-bounds read in libheif 1.23.1 persists because the patch shipped for GHSA-73p7-m7gg-w2jv did not fully remediate the underlying flaw. Processing a specially crafted HEIF or HEIC image file can trigger a read beyond allocated buffer bounds, potentially leaking heap memory contents or crashing the parsing application. Ubuntu has flagged this regression, meaning deployments that upgraded to 1.23.1 expecting full protection remain exposed to the original vulnerability class.
Out-of-bounds read in libheif 1.23.1 persists because the upstream patch for GHSA-73p7-m7gg-w2jv was incomplete, leaving the library still vulnerable in its latest release at time of disclosure. Any application or pipeline that uses libheif to parse HEIF/HEIC image files - including desktop viewers, photo management tools, and server-side media processors - is exposed when handling untrusted image input. The practical impact is at minimum information disclosure (heap memory leak) and potential application crash; no public exploit has been identified at time of analysis.
Stack corruption with potential code execution in MOOS core-moos through version 10.4.0 arises from an off-by-one error in CMOOSSerialPort::GetTelegram(), where a NUL terminator is written one byte past the end of a fixed-size stack buffer. An attacker who controls the serial communication line connected to a MOOS-enabled platform can send a full-length telegram to trigger the overwrite, corrupting adjacent stack memory and potentially redirecting execution. A vendor patch is available via GitHub PR #73 and commit befb04df; no public exploit has been identified at time of analysis.
Stack-based buffer overflow in OpenVPN's Windows service component (openvpnserv) affects versions 2.5.0 through 2.7.6, requiring high attack complexity and passive user interaction to trigger. The flaw produces limited integrity and availability impact on the vulnerable Windows system and marginally on downstream systems in the VPN path. Fixed in v2.7.7, released on GitHub and announced via the OpenVPN community security page, alongside several other Windows-specific CVEs addressed in the same release cycle. No public exploit or active exploitation has been identified at time of analysis.
Heap buffer out-of-bounds write in the MongoDB C Driver's BSON-to-JSON conversion helpers allows an unauthenticated party who supplies document content to corrupt a small number of bytes past the end of a heap-allocated buffer. The overflow is triggered specifically when a binary BSON field is being encoded and the caller has configured a maximum output length that causes the conversion to be cut short. Impact is limited to a low-integrity write of a few bytes adjacent to the buffer - no confidentiality loss and no confirmed availability impact - but heap corruption in native C applications can have unpredictable downstream effects depending on allocator layout. No public exploit code and no CISA KEV listing exist at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: selinux: reject a class permission count below its inherited common security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected.
In the Linux kernel, the following vulnerability has been resolved: selinux: reject a permission value exceeding the class permission count perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. [PM: tweak comment for line length]
Stack-based buffer overflow in slurmstepd, the SLURM job step daemon, can be triggered by an authenticated cluster user who submits a job containing an oversized SPANK (SLURM Plug-in Architecture for Node and job Control) option variable in the job environment. Because slurmstepd typically executes with elevated privileges on compute nodes, successful exploitation could allow a regular SLURM user to achieve privilege escalation or arbitrary code execution on cluster nodes. No public exploit or CISA KEV listing has been identified at time of analysis; this report originates from Ubuntu's vendor security tracking.
Out-of-bounds write in Samsung TizenFX's MediaBufferBase component allows a local low-privileged attacker to corrupt memory by supplying unchecked array indices through the Tizen.Multimedia media buffer API. The vulnerable indexer property in `Tizen.Multimedia.Common.Internal.MediaBufferBase` lacked all bounds validation prior to fixes introduced in upstream PRs #7814 and #7815, admitting negative or oversized index values. Under high-complexity conditions, successful exploitation can produce high integrity and availability impact - crashing the multimedia subsystem or enabling controlled memory corruption - on Tizen-based devices such as Samsung Smart TVs and Galaxy Watch wearables. No public exploit exists and no active exploitation has been confirmed.
Buffer overflow (CWE-119) in the Drupal Gammu SMS Daemon contributed module exposes high-privilege authenticated administrators to memory corruption that yields both confidentiality and integrity compromise. The vulnerability affects all released versions of the module (*.* wildcard CPE), with no patched release confirmed in the provided data. No public exploit code or CISA KEV listing has been identified at time of analysis, and the high attack complexity combined with the requirement for elevated Drupal privileges substantially limits opportunistic exploitation.
Buffer overflow in the Drupal Gammu SMS Daemon contributed module exposes sites to memory corruption with high confidentiality and integrity impact. The vulnerability (CWE-119) requires network-reachable access by a highly privileged user under specific conditions, limiting its practical reach but making it serious when those conditions are met. No public exploit code has been identified at time of analysis, and the Drupal security team has issued advisory SA-contrib-2026-100.
Buffer overflow (CWE-119) in the Drupal Gammu SMS Daemon contributed module allows a highly privileged, authenticated attacker to achieve high confidentiality and integrity impact against affected Drupal installations. The CVSS vector (PR:H, AC:H) constrains real-world exploitability significantly, requiring both administrative access and complex attack conditions. No active exploitation has been identified; all tracked versions of the module are reported as affected with no specific patched release confirmed in available data.
Stack overflow vulnerabilities in an HPE AOS-CX API endpoint allow an authenticated, high-privileged attacker to crash the affected system via a crafted request, resulting in a denial-of-service condition. The vulnerability is network-exploitable but requires prior administrative authentication, substantially limiting the attacker pool. This CVE is part of the same HPE advisory (hpesbnw05134) covering multiple AOS-CX weaknesses, including higher-severity unauthenticated and adjacent-network issues; no public exploit or CISA KEV listing has been identified at time of analysis.
Buffer overflow conditions in an underlying network service of HPE AOS-CX allow unauthenticated attackers on the adjacent network segment to crash the device by sending specially crafted packets, causing a denial-of-service disruption to normal OS operation. This vulnerability is one of several disclosed together under HPE advisory hpesbnw05134, affecting the CX series switch OS. No public exploit code or active exploitation has been identified at time of analysis.
Crash of the gvfsd-mtp daemon in gvfs is achievable by anyone who can connect a malicious USB MTP device to a target Linux system. The do_read() function in gvfsbackendmtp.c accepts the byte-count reported by the device at face value and passes it uncapped to memcpy(), causing an out-of-bounds read that triggers a segmentation fault when the device deliberately over-reports its response length. The vulnerability affects gvfs as packaged across Red Hat Enterprise Linux 6 through 10; no public exploit has been identified and exploitation is constrained by physical proximity.
Heap buffer overflow in the gvfs AFP (Apple Filing Protocol) backend allows a malicious AFP server to crash the gvfsd-afp process on connecting clients, resulting in denial of service. When a client mounts an AFP share, the DSI (Data Stream Interface) read path accepts a server-supplied length value without validating it against the pre-allocated reply buffer, enabling the server to write past buffer boundaries. This affects RHEL 6 through 10 and requires user interaction to mount a malicious share; no public exploit or CISA KEV listing has been identified at time of analysis.
Denial-of-service vulnerability in Rockwell Automation FactoryTalk® Historian Machine Edition allows a network-adjacent, high-privilege authenticated attacker to crash the device by sending crafted requests to its web interface, triggering a stack-based buffer overflow (CWE-121) that renders the historian unresponsive. All versions appear affected per the CPE wildcard, and the impact is limited to availability - no confidentiality or integrity compromise is possible. No public exploit code exists and the vulnerability is not listed in CISA KEV at time of analysis.
Remote code execution in Rockwell Automation FactoryTalk® Historian Machine Edition allows an adjacent-network attacker holding low-privilege credentials to fully compromise the historian host via a memory corruption flaw. The root cause is CWE-787 (Out-of-bounds Write), consistent with a buffer overflow in the historian's network-facing service, yielding full confidentiality, integrity, and availability impact on the affected device. No active exploitation has been confirmed in CISA KEV and no public proof-of-concept has been identified at the time of analysis.
Incorrect boundary conditions in Firefox's CSS Grid layout engine expose limited browser process memory to remote attackers who deliver crafted web content. All Firefox versions prior to 155 are affected; exploitation requires a victim to visit or render attacker-controlled content, producing low-level confidentiality disclosure with no integrity or availability impact. Mozilla issued the fix in Firefox 155 via MFSA2026-82; no public exploit code and no CISA KEV listing have been identified at time of analysis.
Heap metadata corruption in the popt command-line parsing library's `poptConfigFileToString` function can be triggered by a local, low-privileged attacker who supplies specially crafted configuration file content to an affected host. Successful exploitation causes the consuming process to crash, resulting in denial of service. CVSS 2.5 (Low) reflects the strictly local, high-complexity exploitation path with no confidentiality or integrity impact; no public exploit code or active exploitation (CISA KEV) is known at time of analysis.
Buffer overflow in FFmpeg v.7.0 and later within the libavformat/iamf_writer.c component allows an attacker to crash the process by supplying a crafted IAMF (Immersive Audio Model and Formats) file, resulting in a denial of service. The flaw, rooted in improper bounds checking during extradata padding operations (CWE-120), affects the IAMF audio encoder/writer path introduced alongside IAMF support in FFmpeg 7.0. A patch commit (8439e020) and upstream pull request #22988 are available, though a tagged release incorporating the fix has not been independently confirmed. No public exploit code has been identified and EPSS of 0.17% (7th percentile) reflects low exploitation probability at this time.
Off-by-one out-of-bounds write in Zephyr RTOS's LwM2M JSON formatter allows a LwM2M server peer to corrupt one byte of memory adjacent to a STRING resource buffer by sending a WRITE payload whose string length exactly equals the buffer size. Affected devices are Zephyr LwM2M clients with the JSON content formatter enabled (cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:*). The overflow deterministically writes a NUL byte past the buffer boundary, enabling potential crash or silent data corruption depending on memory layout; no public exploit has been identified at time of analysis, but the fix commit and security advisory are publicly visible.
Heap-based buffer overflow in FLVMeta versions up to 1.2.2 allows remote attackers to trigger a crash via a crafted FLV file that manipulates the length argument passed to amf_string_new() during AMF string processing. A public proof-of-concept exists, but the CVSS 4.0 score of 2.1 reflects the strictly limited impact - low-severity availability disruption only, with no confidentiality or integrity consequences. The project maintainer has publicly disputed that the reported bugs are practically exploitable, further tempering the real-world risk assessment.
Race condition in Zephyr RTOS's I3C IBI workqueue subsystem allows a physically-present attacker controlling an I3C peripheral to corrupt kernel memory structures, most realistically causing denial of service. The unsynchronized free-list (sys_slist_t) shared between ISR context and the workqueue handler thread creates a window where a work node can be handed to two consumers simultaneously or a garbage pointer can be dereferenced in a memcpy, producing an out-of-bounds write. No public exploit code has been identified and no CISA KEV listing exists; the patch wrapping all free-list operations in a k_spinlock is confirmed in upstream commit e87e7e2.
Use-after-free in Valkey 9.1.0's blocked-on-keys subsystem allows a high-privilege authenticated attacker to crash the server by triggering a reentrant client teardown during ready-key iteration. When a key becomes ready and multiple clients are unblocked simultaneously, a reply callback for the first-served client can invoke CLIENT KILL on a successor client, freeing that client's memory while the iterator in `handleClientsBlockedOnKey` still holds a reference to it. A public proof-of-concept exists; the vulnerability is not in CISA KEV, and the high complexity and privilege requirements substantially limit practical exploitation.
Out-of-bounds read in Systerel S2OPC versions up to 1.7.3 allows an authenticated remote attacker to partially disrupt availability of an OPC UA server through crafted string array range write operations. The vulnerable function set_range_matrix_on_string_array in sopc_builtintypes.c fails to enforce memory boundaries during range matrix processing on string arrays. No vendor patch has been released; the project was notified via issue report but has not responded. No public exploit or CISA KEV listing exists at time of analysis.
Out-of-bounds read in Kamailio's IMS AVP handler exposes telecom infrastructure to remote memory disclosure and potential service disruption. The `get_4bytes()` function across five IMS modules - `ims_auth`, `ims_icscf`, `ims_registrar_scscf`, `ims_charging`, and `ims_ocs` - fails to validate that Diameter AVP data buffers contain at least 4 bytes before reading, allowing a remote attacker with low-privilege Diameter interface access to trigger the flaw via a crafted malformed message. Publicly available exploit code exists per GitHub issue #4816, and the vendor has confirmed that the 5.5.0 branch is end-of-life and will receive no further security updates, compounding risk for operators running that release.
Memory corruption in LatencyUtils 2.0.3 and earlier allows a local low-privileged user to cause availability disruption by manipulating input to the `LatencyStats.recordDetectedPause` function in the PauseDetector component. A public proof-of-concept has been disclosed via a GitHub issue, and the project maintainers have not responded to the disclosure, leaving the library without an upstream fix. The CVSS 4.0 score of 1.9 and availability-only impact (VA:L) reflect a tightly scoped, low-severity flaw with no confidentiality or integrity consequences and no confirmed active exploitation.
Out-of-bounds read in Exiv2's RemoteIo::Impl::populateBlocks() function affects versions prior to 0.28.9, exploitable only when the tool is invoked against a remote URL rather than a local file. An attacker controlling a remote server can serve a crafted image to trigger the read when a user runs exiv2 against that URL, potentially causing information disclosure or a crash. No public exploit code or active exploitation has been identified; the vulnerability is rated low severity and fixed in the 0.28.9 release.
Heap-based buffer overflow in Open Asset Import Library (Assimp) through version 6.0.2 allows a local low-privilege attacker to corrupt heap memory by supplying a crafted MD5 mesh file. The root cause, confirmed by the patch diff, is that `MakeDataUnique()` pre-allocated only `faces × 3` vertex slots when the output can grow to `numOrigVerts + faces × 3` - meshes declaring more original vertices than face corners overflow the allocation. No public exploit exists and the vulnerability is absent from CISA KEV; impact is locally bounded with a CVSS 4.0 base score of 4.8.
Memory corruption in Open5GS versions up to 2.7.7 allows a low-privileged remote attacker to crash the Access and Mobility Management Function (AMF) by sending a crafted UE MM context transfer request with an oversized allowedNssai array. The vulnerable function amf_namf_comm_decode_ue_mm_context_list in src/amf/namf-handler.c lacked both null-pointer checks and array bounds enforcement on mmContextList[*].allowedNssai entries, relying instead on ogs_assert() which terminates the process rather than handling the error gracefully. No public exploit is confirmed in CISA KEV, but the CVSS 4.0 vector carries E:P indicating publicly disclosed exploit code exists.
Buffer overflow in NASA Core Flight System (cFS) up to version 7.0.1 allows adjacent-network attackers to corrupt memory through the SBN TCP Module's OS_read function. The MsgSz argument read from incoming TCP messages is not bounds-checked before use, enabling a crafted packet to overflow an internal buffer. No vendor patch exists - NASA did not respond to the coordinated disclosure - and no public exploit or KEV listing has been identified at time of analysis.
Stack-based buffer overflow in NASA Trick 19.6.0's JSONVariableServer component exposes the simulation framework to remote exploitation via crafted TCP requests, with no patch available and no vendor response to disclosure. The vulnerability resides in JSONVariableServerThread::parse_request, where user-supplied network data is processed through an unbounded sscanf call without bounds checking on a stack-allocated buffer. Unauthenticated remote attackers reaching the TCP socket can trigger this overflow, potentially crashing the simulation process or achieving code execution on the host.
Integer overflow in U-Boot's SquashFS filesystem parser (fs/squashfs/sqfs.c, function sqfs_concat_tokens) enables heap under-allocation followed by a heap-based buffer overflow via strcpy() when a crafted SquashFS image with manipulated token lists is processed during boot. All U-Boot releases through v2026.01-rc4 are affected. No public exploit code and no CISA KEV listing have been identified at time of analysis; a confirmed fix is available in v2026.04-rc1 (commit adccdb2).
Heap buffer overflow in U-Boot's do_mv shell command (fs/fs.c) affects all versions through v2026.01-rc4 and allows an attacker with U-Boot shell access to corrupt pre-boot heap memory and potentially execute arbitrary code before any OS-level security controls activate. The flaw is rooted in missing bounds checks during string length addition when constructing move-command path arguments: integer overflow causes a heap under-allocation, which is then overflowed by an unchecked strcpy() call. No public exploit code or active exploitation has been identified, and the upstream fix is confirmed in v2026.04-rc1.
Stack-based buffer overflow in MongoDB BI Connector ODBC Driver allows an authenticated user who can influence the numeric argument of a SQL LIMIT clause to crash the hosting application process or corrupt adjacent stack memory. The vulnerability is gated by a non-default driver configuration: the prefetch feature must be explicitly enabled, narrowing real-world exposure to that subset of deployments. No public exploit code has been identified and the issue is absent from CISA's Known Exploited Vulnerabilities catalog; however, where conditions are met, availability impact is rated High by the reporter.
Memory corruption in the TP-Link TL-WR841N v14 embedded HTTP service allows an unauthenticated attacker with adjacent network access to trigger a buffer overflow by submitting a crafted multipart/form-data request containing an oversized boundary parameter. The confirmed impact is limited to undefined application behavior resulting from process memory corruption; TP-Link's own advisory and the CVE description both explicitly state that arbitrary code execution, information disclosure, and denial-of-service have not been demonstrated, despite those labels appearing in the CVE tags. No public exploit code has been identified at time of analysis, and this CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.
Heap out-of-bounds read and stack out-of-bounds access in GIMP's file-psd plugin allow an attacker to crash the application or disclose limited memory contents by convincing a user to open a specially crafted PSD image. The flaw affects GIMP as shipped in Red Hat Enterprise Linux 6 through 9 and stems from missing validation of the channel-count parameter during PSD parsing. No active exploitation has been identified; the attack requires local file delivery and deliberate user interaction, significantly constraining real-world risk.
Stack-based buffer overflow vulnerabilities in the PLANET GS-4210-16P2S managed PoE switch web management interface allow a remote authenticated attacker to crash the CGI process and disrupt web-based device administration. Three separate POST parameter handlers in /cgi-bin/dispatcher.cgi - processing usrPass, enbPass, usrName, and usrPass - copy user-supplied input into fixed-size stack buffers without bounds validation, triggering CWE-121 conditions. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; impact is confined to denial of service against the web management plane.
Stack-based buffer overflow and null pointer dereference vulnerabilities in the PLANET GS-4210-16P2S managed PoE switch firmware (all versions before 3.441b260626) allow a remote authenticated attacker to crash the CGI-based web management service by submitting crafted POST requests to RADIUS server configuration handlers. The `web_radiusSrv*_post` handler family in `/cgi-bin/dispatcher.cgi` copies user-controlled parameters into fixed-size stack buffers without bounds checking and dereferences `radName`/`radIp` pointers without confirming their presence. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog at time of analysis; a vendor-released firmware patch is available.
Stack-based buffer overflows in PLANET GS-4210-16P2S managed switch firmware before 3.441b260626 allow a remote administrator to crash the web management interface by sending crafted HTTP POST requests to /cgi-bin/dispatcher.cgi. More than 30 named CGI handler functions - spanning VLAN, SNMP v3, ACL, AAA, DHCP, STP, PoE, and cable diagnostics subsystems - copy attacker-supplied POST parameters into fixed-size stack buffers without length validation. The confirmed impact is denial of service of the web management service; the vulnerability is not listed in CISA KEV and no public exploit code has been identified at time of analysis, though a vendor patch is available.
Heap out-of-bounds read in GIMP's file-pvr plugin exposes users of Red Hat Enterprise Linux 6 through 9 to application crashes and limited heap memory disclosure when opening a crafted PVR image file. The VQ (Vector Quantization) compressed-texture decoder omits mandatory bounds validation, allowing a malicious image to read beyond allocated heap regions. Impact is primarily denial of service via crash, with a secondary low-severity information disclosure path; no public exploit code and no CISA KEV listing are associated with this issue at time of analysis.
Heap out-of-bounds read in GIMP's file-ico plugin allows a local attacker to crash GIMP or leak limited heap memory contents by delivering a specially crafted ICO image file to a victim user. Affected packages span Red Hat Enterprise Linux 6 through 9. No public exploit code or CISA KEV listing exists at time of analysis, but the user-interaction requirement (opening a malicious file) is the primary delivery mechanism and a realistic social-engineering target in image-processing workflows.
Out-of-bounds memory write in libsolv crashes RPM-based package manager tools (dnf, yum, zypper) when processing a corrupted or specially crafted .solv repository cache file. The root cause is an absent array-index bounds check on directory-id values read from compressed filelist data during .solv file rewriting - but because the out-of-bounds write stores only a fixed, non-attacker-controlled value, the vendor explicitly rules out arbitrary code execution, confining impact to denial of service. No public exploit has been identified and no active exploitation is confirmed; note that the 'RCE' metadata tag conflicts directly with the description and appears to be erroneous.
Heap out-of-bounds read in GIMP's file-iff plugin allows a local attacker to crash the application or disclose limited heap memory contents by delivering a specially crafted IFF/ILBM image file. The flaw stems from missing validation of HAM row size when the number of color planes (nPlanes) is zero, causing a size mismatch that bypasses memory bounds checking. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis.
Stack buffer overflow in Ericsson CodeChecker through 6.28.2 results from an off-by-two error introduced during the CVE-2025-40843 remediation: the safe_strcpy() call at ldlogger-tool-gcc.c:129 receives destination pointer fullPath + 2 but the full PATH_MAX (4096) as its size bound, causing a deterministic 2-byte overwrite past the 4094 bytes that actually remain on every invocation of the GCC logger component. The overflow is unconditional and input-independent; a proof-of-concept is noted via the CVSS 4.0 E:P supplemental metric, though no active exploitation (CISA KEV) has been confirmed.
Authenticated availability disruption in OX Dovecot Pro and OX Dovecot CE allows any valid credential holder to crash the imap-hibernate service by opening many concurrent connections and sending malformed IMAP commands, triggering an intermittent out-of-bounds read (CWE-125). The crash terminates the imap-hibernate process, dropping hibernated IMAP sessions for co-hosted users and degrading service availability. No public exploit code is known and the vulnerability is not listed in CISA KEV; however, the low attack complexity means any authenticated user on a shared mail platform could attempt disruption.
Memory corruption via out-of-bounds write in OX Dovecot Pro and OX Dovecot CE's ManageSieve service allows authenticated network attackers to crash the ManageSieve process, denying all users the ability to remotely manage Sieve email filter scripts. The root cause is improper handling of extreme numeric literals during Sieve script compilation. The vendor notes that remote code execution may theoretically be achievable via the same memory corruption primitive, though no public exploit demonstrates this; no public exploits are known and the vulnerability is not listed in CISA KEV.
Heap buffer overflow in FFmpeg's TDSC screen-capture codec decoder exposes Red Hat Enterprise Linux AI 3 and OpenShift AI deployments to denial of service or potential arbitrary code execution. The tdsc_load_cursor() function performs erroneous stride-based pointer arithmetic in two locations when rendering cursor data from crafted TDSC video, writing past a heap-allocated buffer boundary. No public exploit or active exploitation has been confirmed at time of analysis, and the upstream fix is available as FFmpeg commit 242ff799c.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB.
In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]
In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ]
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: npc: Fix size of entry2cntr_map KASAN prints below splat. This is caused by allocating counter for reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map is not allocated for reserved entries. BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0 Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14 CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1 Hardware name: Marvell CN106XX board (DT) Workqueue: events work_for_cpu_fn Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x88/0xb4 print_report+0x154/0x458 kasan_report+0xb8/0x194 __asan_store2+0x7c/0xa0 npc_map_mcam_entry_and_cntr+0xb0/0x1a0 rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280 npc_install_flow+0x840/0xfe0 rvu_npc_install_cpt_pass2_entry+0x138/0x190 rvu_nix_init+0x148c/0x2880 rvu_probe+0x1800/0x30b0 local_pci_probe+0x78/0xe0 work_for_cpu_fn+0x30/0x50 process_one_work+0x4cc/0x97c worker_thread+0x360/0x630 kthread+0x1a0/0x1b0 ret_from_fork+0x10/0x20
In the Linux kernel, the following vulnerability has been resolved: MIPS: mm: Fix out-of-bounds write in maar_res_walk() maar_res_walk() uses wi->num_cfg as the index into the fixed-size wi->cfg array, but checks whether the array is full only after it has filled the selected entry. If walk_system_ram_range() reports more than 16 memory ranges, the overflow call writes one struct maar_config past the end of the array before WARN_ON() prevents num_cfg from advancing. Move the full-array check before taking the array slot and return non-zero when the scratch array is full, so walk_system_ram_range() terminates the walk instead of invoking the callback for further ranges.
In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - add response length checks The driver processes response data from device buffers without verifying that the device actually sent enough data. This can lead to out-of-bounds reads or processing stale data. Add checks for the expected response length before accessing the buffers.
Heap-based buffer overflow in WatchGuard Fireware OS's iked process allows an authenticated administrator to crash the IKE daemon by saving a specially crafted configuration, resulting in denial of service and disruption of IPsec VPN services. The CVSS 4.0 score of 6.9 with PR:H reflects the high-privilege requirement, meaning exploitation is gated behind valid administrator credentials. No active exploitation has been identified (not in CISA KEV) and no public exploit code is known at time of analysis.
Heap buffer overflow in GNU C Library (glibc) 2.45 and earlier triggers when an effectively empty string is passed via the ,ccs= mode-argument extension to fopen(), enabling limited heap memory corruption in applications that expose this code path to externally controlled input. The vendor-assigned CVSS 3.1 score of 4.9 (Medium) with a local attack vector and high complexity accurately reflects the narrow preconditions required. No public exploit code has been identified at time of analysis, and the glibc advisory itself explicitly notes this vulnerable usage pattern is absent from mainstream GNU/Linux applications.
Out-of-bounds write in gdk-pixbuf's JPEG decoder affects any application on Red Hat Enterprise Linux 6 through 10 that renders JPEG images containing chunked ICC profile markers. When ICC profile parsing encounters an error, stale size metadata persists after the profile buffer is freed; a subsequent allocation within the same decode operation then writes beyond buffer boundaries, crashing the application. No active exploitation has been identified (no CISA KEV listing), and no public exploit code is known at time of analysis, but the availability-only impact and user-interaction requirement make this a realistic denial-of-service risk in desktop and server image-processing contexts.
Out-of-bounds read in Adobe DNG SDK 1.7.1 2502 and earlier exposes sensitive memory contents when a victim opens a maliciously crafted DNG file. The flaw resides in the SDK's file parser and affects any application built on top of the DNG SDK that processes untrusted DNG inputs. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, limiting current urgency despite the High confidentiality impact.
Out-of-bounds write in Adobe DNG Software Development Kit versions 1.7.1 2502 and earlier allows memory corruption when a victim opens a maliciously crafted DNG file, causing the consuming application to crash or become unresponsive. The flaw (CWE-787) is constrained to a local, user-interaction-dependent attack path, limiting automated exploitation. No public exploit code has been identified at time of analysis and no CISA KEV listing exists.
Out-of-bounds heap read in the DHCPv4 packet capture code of wicked (all versions through 0.6.80) allows an unauthenticated attacker on the same Layer-2 network segment to send a crafted DHCP/UDP packet that causes wickedd-dhcp4 to read up to 68 bytes past the end of its 1500-byte receive buffer. Adjacent heap contents - including allocator metadata and pointer values - may be parsed as DHCP options and stored into lease fields, constituting limited information disclosure with a secondary low-integrity configuration impact. No public exploit code and no CISA KEV listing have been identified at time of analysis; an upstream fix exists in GitHub PR #1079, though a tagged release version has not been independently confirmed.
Integer underflow in the wicked DHCPv4 packet capture daemon (wickedd-dhcp4) on SUSE Linux systems allows an unauthenticated adjacent-network attacker to crash the daemon by sending a malformed DHCPv4 packet with an IP total length field smaller than the IP header length. The missing bounds check in ni_capture_inspect_udp_header() triggers an out-of-bounds read, causing a process crash depending on memory layout - resulting in a denial of service to network configuration. No information disclosure has been demonstrated, and no public exploit or CISA KEV listing exists at time of analysis.
Stack buffer overflow in PJSIP's (pjproject) telnet CLI front-end allows unauthenticated network attackers to crash applications that have explicitly enabled the telnet administration interface. The functions send_err_arg() and send_ambi_arg() in cli_telnet.c wrote an attacker-influenced number of bytes into a fixed 256-byte stack buffer without bounds checking, with the error-position offset derived directly from parsed command input. The vulnerability is limited to application termination (DoS); no public exploit code has been identified at time of analysis, and the upstream fix is available as commit 4472a31.
Stack-based buffer overflow in PJSIP pjproject's telnet CLI front-end allows remote, unauthenticated attackers to crash the affected application by sending history-recall input sequences (arrow keys) to the `handle_up_down()` function in `cli_telnet.c`. The accumulated redraw data - comprising cursor position, current buffer length, and recalled history entry length - can exceed the fixed-size `PJ_CLI_MAX_CMDBUF` stack buffer, leading to application termination. Exploitation requires the telnet CLI front-end to be explicitly enabled; applications that do not enable this feature are entirely unaffected, and no public exploit or KEV listing has been identified at time of analysis.
Off-by-one buffer overflow in pjproject's SIP message serialization function allows a remote peer to trigger a single-byte out-of-bounds write by sending crafted SIP requests to a proxy, SBC, or B2BUA that parses and re-serializes messages using the PJSIP library. The vulnerable function `pjsip_generic_array_hdr_print()` in `sip_msg.c` omitted bounds checking before writing the colon and space characters that follow generic array header names (Allow, Require, Supported, Unsupported), resulting in CWE-193 off-by-one writes at exact buffer boundaries. No public exploit has been identified at time of analysis; the vendor explicitly states that code execution and information disclosure have not been demonstrated, and pool-based allocator slack typically absorbs the errant byte harmlessly.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: use check_add_overflow for shader size+offset bound vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size.
In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the attribute-list entry in ntfs_read_inode_mount() The $MFT attribute-list walk in ntfs_read_inode_mount() validates each entry only with "(u8 *)al_entry + 6 > al_end" and "(u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end", but then reads al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference (offset 16) -- fields beyond the 6 bytes proven in range. al_entry->length is attacker-controlled and only required non-zero, so a short entry (e.g. length 8) placed at the tail passes both checks while the lowest_vcn / mft_reference reads fall past al_end. al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding usually absorbs the over-read -- but when attr_list_size is a multiple of SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an out-of-bounds read at mount time. Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing it, matching the bound the other attribute-list walks now use. The validator already requires the length to cover the fixed header, which makes the separate "!al_entry->length" check redundant, so drop it too.
Stack-based buffer overflow in IBM i 7.3 through 7.6 allows remote authenticated attackers to cause a denial of service by sending specially crafted network input that exceeds a stack-allocated buffer in a network-accessible component. The vulnerability is gated behind low-privilege authentication (PR:L) and carries no confidentiality or integrity impact, as IBM's advisory scores it CVSS 4.3 with A:L. No public exploit code or active exploitation has been identified; a vendor-released patch is available via the IBM support portal.
Stack-based buffer overflow in IBM i 7.3 through 7.6 allows an authenticated local attacker to crash the system, producing a denial of service with no confidentiality or integrity impact. The flaw is classified as CWE-121 and is limited in severity by both the access prerequisites and the bounded availability-only outcome. A vendor patch is available via IBM's support portal, and no public exploit code has been identified at time of analysis.
Denial of service on IBM i versions 7.3 through 7.6 is achievable by exploiting an off-by-one write in the LPD (Line Printer Daemon) queue name parser, corrupting adjacent memory and crashing the affected service. The vendor description specifies a local authenticated attacker as the threat actor, yet IBM's own submitted CVSS vector (AV:N/AC:L/PR:N/UI:N) characterizes this as an unauthenticated network-reachable flaw - a direct contradiction that materially affects risk prioritization. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 </TASK> Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---
In the Linux kernel, the following vulnerability has been resolved: tls: device: fix out-of-bounds write in tls_append_frag() Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK> and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: <TASK> worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK>
In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.
In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.
In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - bound the akcipher result length virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: gb_len = atr_req->length - sizeof(struct st21nfca_atr_req); ... memcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.
In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.
In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec() io_vec_fill_bvec() computes the folio size with a plain int 1: unsigned long folio_size = 1 << imu->folio_shift; imu->folio_shift is unsigned int and comes from folio_shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio_shift shift in this file already uses 1UL. The result is that the segment estimate and the fill loop disagree. io_estimate_bvec_size() sizes the bvec array with the real shift: max_segs += (iov[i].iov_len >> shift) + 2; so a 1M iovec on a 16G folio is charged 2 segments, while io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4 bytes and writes res_bvec[bvec_idx] a quarter of a million times, past the end of the array it was given. src_bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate_fixed_range() only checks that the range is inside the registered buffer and does not bound the segment count. Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registers that size, and likewise on powerpc. x86_64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected. Use 1UL, as the rest of the file does.
In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.
In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.
In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes tlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 ("net: nfc: nci: Fix parameter validation for packet data"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().
In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a "size < 1" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: hid_dump_input(field->report->device, field->usage + offset, value); if (offset >= field->report_count) { hid_err(...); return -1; } Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs "offset (1) exceeds report_count (1)" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Use the same sizeof(struct joycon_input_report) bound here.
Out-of-bounds read in libheif 1.23.1 persists because the patch shipped for GHSA-73p7-m7gg-w2jv did not fully remediate the underlying flaw. Processing a specially crafted HEIF or HEIC image file can trigger a read beyond allocated buffer bounds, potentially leaking heap memory contents or crashing the parsing application. Ubuntu has flagged this regression, meaning deployments that upgraded to 1.23.1 expecting full protection remain exposed to the original vulnerability class.
Out-of-bounds read in libheif 1.23.1 persists because the upstream patch for GHSA-73p7-m7gg-w2jv was incomplete, leaving the library still vulnerable in its latest release at time of disclosure. Any application or pipeline that uses libheif to parse HEIF/HEIC image files - including desktop viewers, photo management tools, and server-side media processors - is exposed when handling untrusted image input. The practical impact is at minimum information disclosure (heap memory leak) and potential application crash; no public exploit has been identified at time of analysis.
Stack corruption with potential code execution in MOOS core-moos through version 10.4.0 arises from an off-by-one error in CMOOSSerialPort::GetTelegram(), where a NUL terminator is written one byte past the end of a fixed-size stack buffer. An attacker who controls the serial communication line connected to a MOOS-enabled platform can send a full-length telegram to trigger the overwrite, corrupting adjacent stack memory and potentially redirecting execution. A vendor patch is available via GitHub PR #73 and commit befb04df; no public exploit has been identified at time of analysis.
Stack-based buffer overflow in OpenVPN's Windows service component (openvpnserv) affects versions 2.5.0 through 2.7.6, requiring high attack complexity and passive user interaction to trigger. The flaw produces limited integrity and availability impact on the vulnerable Windows system and marginally on downstream systems in the VPN path. Fixed in v2.7.7, released on GitHub and announced via the OpenVPN community security page, alongside several other Windows-specific CVEs addressed in the same release cycle. No public exploit or active exploitation has been identified at time of analysis.
Heap buffer out-of-bounds write in the MongoDB C Driver's BSON-to-JSON conversion helpers allows an unauthenticated party who supplies document content to corrupt a small number of bytes past the end of a heap-allocated buffer. The overflow is triggered specifically when a binary BSON field is being encoded and the caller has configured a maximum output length that causes the conversion to be cut short. Impact is limited to a low-integrity write of a few bytes adjacent to the buffer - no confidentiality loss and no confirmed availability impact - but heap corruption in native C applications can have unpredictable downstream effects depending on allocator layout. No public exploit code and no CISA KEV listing exist at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: selinux: reject a class permission count below its inherited common security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected.
In the Linux kernel, the following vulnerability has been resolved: selinux: reject a permission value exceeding the class permission count perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. [PM: tweak comment for line length]
Stack-based buffer overflow in slurmstepd, the SLURM job step daemon, can be triggered by an authenticated cluster user who submits a job containing an oversized SPANK (SLURM Plug-in Architecture for Node and job Control) option variable in the job environment. Because slurmstepd typically executes with elevated privileges on compute nodes, successful exploitation could allow a regular SLURM user to achieve privilege escalation or arbitrary code execution on cluster nodes. No public exploit or CISA KEV listing has been identified at time of analysis; this report originates from Ubuntu's vendor security tracking.
Out-of-bounds write in Samsung TizenFX's MediaBufferBase component allows a local low-privileged attacker to corrupt memory by supplying unchecked array indices through the Tizen.Multimedia media buffer API. The vulnerable indexer property in `Tizen.Multimedia.Common.Internal.MediaBufferBase` lacked all bounds validation prior to fixes introduced in upstream PRs #7814 and #7815, admitting negative or oversized index values. Under high-complexity conditions, successful exploitation can produce high integrity and availability impact - crashing the multimedia subsystem or enabling controlled memory corruption - on Tizen-based devices such as Samsung Smart TVs and Galaxy Watch wearables. No public exploit exists and no active exploitation has been confirmed.
Buffer overflow (CWE-119) in the Drupal Gammu SMS Daemon contributed module exposes high-privilege authenticated administrators to memory corruption that yields both confidentiality and integrity compromise. The vulnerability affects all released versions of the module (*.* wildcard CPE), with no patched release confirmed in the provided data. No public exploit code or CISA KEV listing has been identified at time of analysis, and the high attack complexity combined with the requirement for elevated Drupal privileges substantially limits opportunistic exploitation.
Buffer overflow in the Drupal Gammu SMS Daemon contributed module exposes sites to memory corruption with high confidentiality and integrity impact. The vulnerability (CWE-119) requires network-reachable access by a highly privileged user under specific conditions, limiting its practical reach but making it serious when those conditions are met. No public exploit code has been identified at time of analysis, and the Drupal security team has issued advisory SA-contrib-2026-100.
Buffer overflow (CWE-119) in the Drupal Gammu SMS Daemon contributed module allows a highly privileged, authenticated attacker to achieve high confidentiality and integrity impact against affected Drupal installations. The CVSS vector (PR:H, AC:H) constrains real-world exploitability significantly, requiring both administrative access and complex attack conditions. No active exploitation has been identified; all tracked versions of the module are reported as affected with no specific patched release confirmed in available data.
Stack overflow vulnerabilities in an HPE AOS-CX API endpoint allow an authenticated, high-privileged attacker to crash the affected system via a crafted request, resulting in a denial-of-service condition. The vulnerability is network-exploitable but requires prior administrative authentication, substantially limiting the attacker pool. This CVE is part of the same HPE advisory (hpesbnw05134) covering multiple AOS-CX weaknesses, including higher-severity unauthenticated and adjacent-network issues; no public exploit or CISA KEV listing has been identified at time of analysis.
Buffer overflow conditions in an underlying network service of HPE AOS-CX allow unauthenticated attackers on the adjacent network segment to crash the device by sending specially crafted packets, causing a denial-of-service disruption to normal OS operation. This vulnerability is one of several disclosed together under HPE advisory hpesbnw05134, affecting the CX series switch OS. No public exploit code or active exploitation has been identified at time of analysis.
Crash of the gvfsd-mtp daemon in gvfs is achievable by anyone who can connect a malicious USB MTP device to a target Linux system. The do_read() function in gvfsbackendmtp.c accepts the byte-count reported by the device at face value and passes it uncapped to memcpy(), causing an out-of-bounds read that triggers a segmentation fault when the device deliberately over-reports its response length. The vulnerability affects gvfs as packaged across Red Hat Enterprise Linux 6 through 10; no public exploit has been identified and exploitation is constrained by physical proximity.
Heap buffer overflow in the gvfs AFP (Apple Filing Protocol) backend allows a malicious AFP server to crash the gvfsd-afp process on connecting clients, resulting in denial of service. When a client mounts an AFP share, the DSI (Data Stream Interface) read path accepts a server-supplied length value without validating it against the pre-allocated reply buffer, enabling the server to write past buffer boundaries. This affects RHEL 6 through 10 and requires user interaction to mount a malicious share; no public exploit or CISA KEV listing has been identified at time of analysis.
Denial-of-service vulnerability in Rockwell Automation FactoryTalk® Historian Machine Edition allows a network-adjacent, high-privilege authenticated attacker to crash the device by sending crafted requests to its web interface, triggering a stack-based buffer overflow (CWE-121) that renders the historian unresponsive. All versions appear affected per the CPE wildcard, and the impact is limited to availability - no confidentiality or integrity compromise is possible. No public exploit code exists and the vulnerability is not listed in CISA KEV at time of analysis.
Remote code execution in Rockwell Automation FactoryTalk® Historian Machine Edition allows an adjacent-network attacker holding low-privilege credentials to fully compromise the historian host via a memory corruption flaw. The root cause is CWE-787 (Out-of-bounds Write), consistent with a buffer overflow in the historian's network-facing service, yielding full confidentiality, integrity, and availability impact on the affected device. No active exploitation has been confirmed in CISA KEV and no public proof-of-concept has been identified at the time of analysis.
Incorrect boundary conditions in Firefox's CSS Grid layout engine expose limited browser process memory to remote attackers who deliver crafted web content. All Firefox versions prior to 155 are affected; exploitation requires a victim to visit or render attacker-controlled content, producing low-level confidentiality disclosure with no integrity or availability impact. Mozilla issued the fix in Firefox 155 via MFSA2026-82; no public exploit code and no CISA KEV listing have been identified at time of analysis.
Heap metadata corruption in the popt command-line parsing library's `poptConfigFileToString` function can be triggered by a local, low-privileged attacker who supplies specially crafted configuration file content to an affected host. Successful exploitation causes the consuming process to crash, resulting in denial of service. CVSS 2.5 (Low) reflects the strictly local, high-complexity exploitation path with no confidentiality or integrity impact; no public exploit code or active exploitation (CISA KEV) is known at time of analysis.
Buffer overflow in FFmpeg v.7.0 and later within the libavformat/iamf_writer.c component allows an attacker to crash the process by supplying a crafted IAMF (Immersive Audio Model and Formats) file, resulting in a denial of service. The flaw, rooted in improper bounds checking during extradata padding operations (CWE-120), affects the IAMF audio encoder/writer path introduced alongside IAMF support in FFmpeg 7.0. A patch commit (8439e020) and upstream pull request #22988 are available, though a tagged release incorporating the fix has not been independently confirmed. No public exploit code has been identified and EPSS of 0.17% (7th percentile) reflects low exploitation probability at this time.
Off-by-one out-of-bounds write in Zephyr RTOS's LwM2M JSON formatter allows a LwM2M server peer to corrupt one byte of memory adjacent to a STRING resource buffer by sending a WRITE payload whose string length exactly equals the buffer size. Affected devices are Zephyr LwM2M clients with the JSON content formatter enabled (cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:*). The overflow deterministically writes a NUL byte past the buffer boundary, enabling potential crash or silent data corruption depending on memory layout; no public exploit has been identified at time of analysis, but the fix commit and security advisory are publicly visible.
Heap-based buffer overflow in FLVMeta versions up to 1.2.2 allows remote attackers to trigger a crash via a crafted FLV file that manipulates the length argument passed to amf_string_new() during AMF string processing. A public proof-of-concept exists, but the CVSS 4.0 score of 2.1 reflects the strictly limited impact - low-severity availability disruption only, with no confidentiality or integrity consequences. The project maintainer has publicly disputed that the reported bugs are practically exploitable, further tempering the real-world risk assessment.
Race condition in Zephyr RTOS's I3C IBI workqueue subsystem allows a physically-present attacker controlling an I3C peripheral to corrupt kernel memory structures, most realistically causing denial of service. The unsynchronized free-list (sys_slist_t) shared between ISR context and the workqueue handler thread creates a window where a work node can be handed to two consumers simultaneously or a garbage pointer can be dereferenced in a memcpy, producing an out-of-bounds write. No public exploit code has been identified and no CISA KEV listing exists; the patch wrapping all free-list operations in a k_spinlock is confirmed in upstream commit e87e7e2.
Use-after-free in Valkey 9.1.0's blocked-on-keys subsystem allows a high-privilege authenticated attacker to crash the server by triggering a reentrant client teardown during ready-key iteration. When a key becomes ready and multiple clients are unblocked simultaneously, a reply callback for the first-served client can invoke CLIENT KILL on a successor client, freeing that client's memory while the iterator in `handleClientsBlockedOnKey` still holds a reference to it. A public proof-of-concept exists; the vulnerability is not in CISA KEV, and the high complexity and privilege requirements substantially limit practical exploitation.
Out-of-bounds read in Systerel S2OPC versions up to 1.7.3 allows an authenticated remote attacker to partially disrupt availability of an OPC UA server through crafted string array range write operations. The vulnerable function set_range_matrix_on_string_array in sopc_builtintypes.c fails to enforce memory boundaries during range matrix processing on string arrays. No vendor patch has been released; the project was notified via issue report but has not responded. No public exploit or CISA KEV listing exists at time of analysis.
Out-of-bounds read in Kamailio's IMS AVP handler exposes telecom infrastructure to remote memory disclosure and potential service disruption. The `get_4bytes()` function across five IMS modules - `ims_auth`, `ims_icscf`, `ims_registrar_scscf`, `ims_charging`, and `ims_ocs` - fails to validate that Diameter AVP data buffers contain at least 4 bytes before reading, allowing a remote attacker with low-privilege Diameter interface access to trigger the flaw via a crafted malformed message. Publicly available exploit code exists per GitHub issue #4816, and the vendor has confirmed that the 5.5.0 branch is end-of-life and will receive no further security updates, compounding risk for operators running that release.
Memory corruption in LatencyUtils 2.0.3 and earlier allows a local low-privileged user to cause availability disruption by manipulating input to the `LatencyStats.recordDetectedPause` function in the PauseDetector component. A public proof-of-concept has been disclosed via a GitHub issue, and the project maintainers have not responded to the disclosure, leaving the library without an upstream fix. The CVSS 4.0 score of 1.9 and availability-only impact (VA:L) reflect a tightly scoped, low-severity flaw with no confidentiality or integrity consequences and no confirmed active exploitation.
Out-of-bounds read in Exiv2's RemoteIo::Impl::populateBlocks() function affects versions prior to 0.28.9, exploitable only when the tool is invoked against a remote URL rather than a local file. An attacker controlling a remote server can serve a crafted image to trigger the read when a user runs exiv2 against that URL, potentially causing information disclosure or a crash. No public exploit code or active exploitation has been identified; the vulnerability is rated low severity and fixed in the 0.28.9 release.
Heap-based buffer overflow in Open Asset Import Library (Assimp) through version 6.0.2 allows a local low-privilege attacker to corrupt heap memory by supplying a crafted MD5 mesh file. The root cause, confirmed by the patch diff, is that `MakeDataUnique()` pre-allocated only `faces × 3` vertex slots when the output can grow to `numOrigVerts + faces × 3` - meshes declaring more original vertices than face corners overflow the allocation. No public exploit exists and the vulnerability is absent from CISA KEV; impact is locally bounded with a CVSS 4.0 base score of 4.8.
Memory corruption in Open5GS versions up to 2.7.7 allows a low-privileged remote attacker to crash the Access and Mobility Management Function (AMF) by sending a crafted UE MM context transfer request with an oversized allowedNssai array. The vulnerable function amf_namf_comm_decode_ue_mm_context_list in src/amf/namf-handler.c lacked both null-pointer checks and array bounds enforcement on mmContextList[*].allowedNssai entries, relying instead on ogs_assert() which terminates the process rather than handling the error gracefully. No public exploit is confirmed in CISA KEV, but the CVSS 4.0 vector carries E:P indicating publicly disclosed exploit code exists.
Buffer overflow in NASA Core Flight System (cFS) up to version 7.0.1 allows adjacent-network attackers to corrupt memory through the SBN TCP Module's OS_read function. The MsgSz argument read from incoming TCP messages is not bounds-checked before use, enabling a crafted packet to overflow an internal buffer. No vendor patch exists - NASA did not respond to the coordinated disclosure - and no public exploit or KEV listing has been identified at time of analysis.
Stack-based buffer overflow in NASA Trick 19.6.0's JSONVariableServer component exposes the simulation framework to remote exploitation via crafted TCP requests, with no patch available and no vendor response to disclosure. The vulnerability resides in JSONVariableServerThread::parse_request, where user-supplied network data is processed through an unbounded sscanf call without bounds checking on a stack-allocated buffer. Unauthenticated remote attackers reaching the TCP socket can trigger this overflow, potentially crashing the simulation process or achieving code execution on the host.
Integer overflow in U-Boot's SquashFS filesystem parser (fs/squashfs/sqfs.c, function sqfs_concat_tokens) enables heap under-allocation followed by a heap-based buffer overflow via strcpy() when a crafted SquashFS image with manipulated token lists is processed during boot. All U-Boot releases through v2026.01-rc4 are affected. No public exploit code and no CISA KEV listing have been identified at time of analysis; a confirmed fix is available in v2026.04-rc1 (commit adccdb2).
Heap buffer overflow in U-Boot's do_mv shell command (fs/fs.c) affects all versions through v2026.01-rc4 and allows an attacker with U-Boot shell access to corrupt pre-boot heap memory and potentially execute arbitrary code before any OS-level security controls activate. The flaw is rooted in missing bounds checks during string length addition when constructing move-command path arguments: integer overflow causes a heap under-allocation, which is then overflowed by an unchecked strcpy() call. No public exploit code or active exploitation has been identified, and the upstream fix is confirmed in v2026.04-rc1.
Stack-based buffer overflow in MongoDB BI Connector ODBC Driver allows an authenticated user who can influence the numeric argument of a SQL LIMIT clause to crash the hosting application process or corrupt adjacent stack memory. The vulnerability is gated by a non-default driver configuration: the prefetch feature must be explicitly enabled, narrowing real-world exposure to that subset of deployments. No public exploit code has been identified and the issue is absent from CISA's Known Exploited Vulnerabilities catalog; however, where conditions are met, availability impact is rated High by the reporter.
Memory corruption in the TP-Link TL-WR841N v14 embedded HTTP service allows an unauthenticated attacker with adjacent network access to trigger a buffer overflow by submitting a crafted multipart/form-data request containing an oversized boundary parameter. The confirmed impact is limited to undefined application behavior resulting from process memory corruption; TP-Link's own advisory and the CVE description both explicitly state that arbitrary code execution, information disclosure, and denial-of-service have not been demonstrated, despite those labels appearing in the CVE tags. No public exploit code has been identified at time of analysis, and this CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.
Heap out-of-bounds read and stack out-of-bounds access in GIMP's file-psd plugin allow an attacker to crash the application or disclose limited memory contents by convincing a user to open a specially crafted PSD image. The flaw affects GIMP as shipped in Red Hat Enterprise Linux 6 through 9 and stems from missing validation of the channel-count parameter during PSD parsing. No active exploitation has been identified; the attack requires local file delivery and deliberate user interaction, significantly constraining real-world risk.
Stack-based buffer overflow vulnerabilities in the PLANET GS-4210-16P2S managed PoE switch web management interface allow a remote authenticated attacker to crash the CGI process and disrupt web-based device administration. Three separate POST parameter handlers in /cgi-bin/dispatcher.cgi - processing usrPass, enbPass, usrName, and usrPass - copy user-supplied input into fixed-size stack buffers without bounds validation, triggering CWE-121 conditions. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; impact is confined to denial of service against the web management plane.
Stack-based buffer overflow and null pointer dereference vulnerabilities in the PLANET GS-4210-16P2S managed PoE switch firmware (all versions before 3.441b260626) allow a remote authenticated attacker to crash the CGI-based web management service by submitting crafted POST requests to RADIUS server configuration handlers. The `web_radiusSrv*_post` handler family in `/cgi-bin/dispatcher.cgi` copies user-controlled parameters into fixed-size stack buffers without bounds checking and dereferences `radName`/`radIp` pointers without confirming their presence. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog at time of analysis; a vendor-released firmware patch is available.
Stack-based buffer overflows in PLANET GS-4210-16P2S managed switch firmware before 3.441b260626 allow a remote administrator to crash the web management interface by sending crafted HTTP POST requests to /cgi-bin/dispatcher.cgi. More than 30 named CGI handler functions - spanning VLAN, SNMP v3, ACL, AAA, DHCP, STP, PoE, and cable diagnostics subsystems - copy attacker-supplied POST parameters into fixed-size stack buffers without length validation. The confirmed impact is denial of service of the web management service; the vulnerability is not listed in CISA KEV and no public exploit code has been identified at time of analysis, though a vendor patch is available.
Heap out-of-bounds read in GIMP's file-pvr plugin exposes users of Red Hat Enterprise Linux 6 through 9 to application crashes and limited heap memory disclosure when opening a crafted PVR image file. The VQ (Vector Quantization) compressed-texture decoder omits mandatory bounds validation, allowing a malicious image to read beyond allocated heap regions. Impact is primarily denial of service via crash, with a secondary low-severity information disclosure path; no public exploit code and no CISA KEV listing are associated with this issue at time of analysis.
Heap out-of-bounds read in GIMP's file-ico plugin allows a local attacker to crash GIMP or leak limited heap memory contents by delivering a specially crafted ICO image file to a victim user. Affected packages span Red Hat Enterprise Linux 6 through 9. No public exploit code or CISA KEV listing exists at time of analysis, but the user-interaction requirement (opening a malicious file) is the primary delivery mechanism and a realistic social-engineering target in image-processing workflows.
Out-of-bounds memory write in libsolv crashes RPM-based package manager tools (dnf, yum, zypper) when processing a corrupted or specially crafted .solv repository cache file. The root cause is an absent array-index bounds check on directory-id values read from compressed filelist data during .solv file rewriting - but because the out-of-bounds write stores only a fixed, non-attacker-controlled value, the vendor explicitly rules out arbitrary code execution, confining impact to denial of service. No public exploit has been identified and no active exploitation is confirmed; note that the 'RCE' metadata tag conflicts directly with the description and appears to be erroneous.
Heap out-of-bounds read in GIMP's file-iff plugin allows a local attacker to crash the application or disclose limited heap memory contents by delivering a specially crafted IFF/ILBM image file. The flaw stems from missing validation of HAM row size when the number of color planes (nPlanes) is zero, causing a size mismatch that bypasses memory bounds checking. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis.
Stack buffer overflow in Ericsson CodeChecker through 6.28.2 results from an off-by-two error introduced during the CVE-2025-40843 remediation: the safe_strcpy() call at ldlogger-tool-gcc.c:129 receives destination pointer fullPath + 2 but the full PATH_MAX (4096) as its size bound, causing a deterministic 2-byte overwrite past the 4094 bytes that actually remain on every invocation of the GCC logger component. The overflow is unconditional and input-independent; a proof-of-concept is noted via the CVSS 4.0 E:P supplemental metric, though no active exploitation (CISA KEV) has been confirmed.
Authenticated availability disruption in OX Dovecot Pro and OX Dovecot CE allows any valid credential holder to crash the imap-hibernate service by opening many concurrent connections and sending malformed IMAP commands, triggering an intermittent out-of-bounds read (CWE-125). The crash terminates the imap-hibernate process, dropping hibernated IMAP sessions for co-hosted users and degrading service availability. No public exploit code is known and the vulnerability is not listed in CISA KEV; however, the low attack complexity means any authenticated user on a shared mail platform could attempt disruption.
Memory corruption via out-of-bounds write in OX Dovecot Pro and OX Dovecot CE's ManageSieve service allows authenticated network attackers to crash the ManageSieve process, denying all users the ability to remotely manage Sieve email filter scripts. The root cause is improper handling of extreme numeric literals during Sieve script compilation. The vendor notes that remote code execution may theoretically be achievable via the same memory corruption primitive, though no public exploit demonstrates this; no public exploits are known and the vulnerability is not listed in CISA KEV.
Heap buffer overflow in FFmpeg's TDSC screen-capture codec decoder exposes Red Hat Enterprise Linux AI 3 and OpenShift AI deployments to denial of service or potential arbitrary code execution. The tdsc_load_cursor() function performs erroneous stride-based pointer arithmetic in two locations when rendering cursor data from crafted TDSC video, writing past a heap-allocated buffer boundary. No public exploit or active exploitation has been confirmed at time of analysis, and the upstream fix is available as FFmpeg commit 242ff799c.
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB.
In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]
In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ]
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: npc: Fix size of entry2cntr_map KASAN prints below splat. This is caused by allocating counter for reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map is not allocated for reserved entries. BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0 Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14 CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1 Hardware name: Marvell CN106XX board (DT) Workqueue: events work_for_cpu_fn Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x88/0xb4 print_report+0x154/0x458 kasan_report+0xb8/0x194 __asan_store2+0x7c/0xa0 npc_map_mcam_entry_and_cntr+0xb0/0x1a0 rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280 npc_install_flow+0x840/0xfe0 rvu_npc_install_cpt_pass2_entry+0x138/0x190 rvu_nix_init+0x148c/0x2880 rvu_probe+0x1800/0x30b0 local_pci_probe+0x78/0xe0 work_for_cpu_fn+0x30/0x50 process_one_work+0x4cc/0x97c worker_thread+0x360/0x630 kthread+0x1a0/0x1b0 ret_from_fork+0x10/0x20
In the Linux kernel, the following vulnerability has been resolved: MIPS: mm: Fix out-of-bounds write in maar_res_walk() maar_res_walk() uses wi->num_cfg as the index into the fixed-size wi->cfg array, but checks whether the array is full only after it has filled the selected entry. If walk_system_ram_range() reports more than 16 memory ranges, the overflow call writes one struct maar_config past the end of the array before WARN_ON() prevents num_cfg from advancing. Move the full-array check before taking the array slot and return non-zero when the scratch array is full, so walk_system_ram_range() terminates the walk instead of invoking the callback for further ranges.
In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - add response length checks The driver processes response data from device buffers without verifying that the device actually sent enough data. This can lead to out-of-bounds reads or processing stale data. Add checks for the expected response length before accessing the buffers.
Heap-based buffer overflow in WatchGuard Fireware OS's iked process allows an authenticated administrator to crash the IKE daemon by saving a specially crafted configuration, resulting in denial of service and disruption of IPsec VPN services. The CVSS 4.0 score of 6.9 with PR:H reflects the high-privilege requirement, meaning exploitation is gated behind valid administrator credentials. No active exploitation has been identified (not in CISA KEV) and no public exploit code is known at time of analysis.
Heap buffer overflow in GNU C Library (glibc) 2.45 and earlier triggers when an effectively empty string is passed via the ,ccs= mode-argument extension to fopen(), enabling limited heap memory corruption in applications that expose this code path to externally controlled input. The vendor-assigned CVSS 3.1 score of 4.9 (Medium) with a local attack vector and high complexity accurately reflects the narrow preconditions required. No public exploit code has been identified at time of analysis, and the glibc advisory itself explicitly notes this vulnerable usage pattern is absent from mainstream GNU/Linux applications.
Out-of-bounds write in gdk-pixbuf's JPEG decoder affects any application on Red Hat Enterprise Linux 6 through 10 that renders JPEG images containing chunked ICC profile markers. When ICC profile parsing encounters an error, stale size metadata persists after the profile buffer is freed; a subsequent allocation within the same decode operation then writes beyond buffer boundaries, crashing the application. No active exploitation has been identified (no CISA KEV listing), and no public exploit code is known at time of analysis, but the availability-only impact and user-interaction requirement make this a realistic denial-of-service risk in desktop and server image-processing contexts.
Out-of-bounds read in Adobe DNG SDK 1.7.1 2502 and earlier exposes sensitive memory contents when a victim opens a maliciously crafted DNG file. The flaw resides in the SDK's file parser and affects any application built on top of the DNG SDK that processes untrusted DNG inputs. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, limiting current urgency despite the High confidentiality impact.
Out-of-bounds write in Adobe DNG Software Development Kit versions 1.7.1 2502 and earlier allows memory corruption when a victim opens a maliciously crafted DNG file, causing the consuming application to crash or become unresponsive. The flaw (CWE-787) is constrained to a local, user-interaction-dependent attack path, limiting automated exploitation. No public exploit code has been identified at time of analysis and no CISA KEV listing exists.
Out-of-bounds heap read in the DHCPv4 packet capture code of wicked (all versions through 0.6.80) allows an unauthenticated attacker on the same Layer-2 network segment to send a crafted DHCP/UDP packet that causes wickedd-dhcp4 to read up to 68 bytes past the end of its 1500-byte receive buffer. Adjacent heap contents - including allocator metadata and pointer values - may be parsed as DHCP options and stored into lease fields, constituting limited information disclosure with a secondary low-integrity configuration impact. No public exploit code and no CISA KEV listing have been identified at time of analysis; an upstream fix exists in GitHub PR #1079, though a tagged release version has not been independently confirmed.
Integer underflow in the wicked DHCPv4 packet capture daemon (wickedd-dhcp4) on SUSE Linux systems allows an unauthenticated adjacent-network attacker to crash the daemon by sending a malformed DHCPv4 packet with an IP total length field smaller than the IP header length. The missing bounds check in ni_capture_inspect_udp_header() triggers an out-of-bounds read, causing a process crash depending on memory layout - resulting in a denial of service to network configuration. No information disclosure has been demonstrated, and no public exploit or CISA KEV listing exists at time of analysis.