Buffer Overflow
Monthly
In libsmpp35 from 0.1.0 through 1.8.0 out of bound read issue was found in the at smpp34_unpack() function via attacker controlled SMPP PDUs, leading to memory corruption.
In osmo-bsc from 1.0.1 through 1.14.1 a heap based buffer overflow issue was found in the ipaccess_proxy_read_msg() function via IPA frame lengths.
In osmo-ggsn 1.14.0 an out of bounds write issue was found in the gtp_decode_pdp_ctx() function through the PDP context GSN-Address sub-field, leading to memory corruption.
Heap-based out-of-bounds write in the PJSIP pjmedia AVI player (pjproject 2.17 and earlier) lets a crafted AVI file overwrite memory beyond a frame buffer when an application plays the file or pulls its frames. The buffer capacity is derived from the video dimensions declared in the file, while the copy length is taken from the file's own chunk header, so a malicious header produces an attacker-controlled write; the protection that would normally catch this is a pj_assert() that is compiled out of production release builds. The issue is local and file-driven, requiring the victim to open the media (CVSS v3.1 AV:L/UI:R, PR:N per the assessed vector), with crash-level impact for ordinary local playback and full memory corruption for applications that ingest untrusted AVI from relays, transcoders or user uploads; no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and no fixed release version is available as of this review.
An integer-wraparound in Cockpit's do_lastlog() login-accounting routine on ILP32 (32-bit) builds allows a low-privileged but authenticated local user holding an administrator-provisioned abnormally large UID to read and modify other users' lastlog records, producing low confidentiality and low integrity impact (CVSS 3.1 base 3.6, AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N). Exploitation requires a 32-bit build, a deliberately created large-UID account, and local access to the host; 64-bit LP64 builds do not overflow and are unaffected, and no public exploit code has been identified at time of analysis.
Heap out-of-bounds read in libheif prior to 1.23.2 lets an application that builds inline-mask region metadata through the library's writer API leak adjacent heap memory or crash. Specifically, heif_region_item_add_region_inline_mask_data() stored a caller-supplied mask buffer without verifying that mask_data_len equals ceil(width*height/8); a later heif_region_get_mask_image() render derives the number of bytes to read from the region geometry, so an undersized buffer causes the reader to copy bytes past the end of the allocation into the returned monochrome mask image. The file-parsing/decode path validates the canonical mask size and is explicitly not vulnerable, so merely opening a crafted HEIF/AVIF file does not trigger the bug; exploitation requires a local program in which attacker-influenced geometry and mask data disagree, consistent with the assessed vector AV:L/AC:H/PR:N/UI:N (CVSS 4.0). There is no confirmed active exploitation (no CISA KEV listing), and no public exploit code was identified at time of analysis; the issue is a genuine but low-priority memory-safety defect rather than an emergency, and version 1.23.2 fixes it.
Denial of service in OpenImageIO versions prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1 occurs when the library processes a truncated TGA file while writing GIF output, triggering a signed 32-bit integer overflow in GifSplitPalette() that leads to an out-of-bounds read (CWE-125) and a process crash. The CVSS v3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) indicates the attacker is unauthenticated (PR:N) but requires local access and user interaction, with no remote or unauthenticated network trigger. No public exploit code or active exploitation has been identified; this is a low-priority hardening issue for workflows that transcode untrusted images to GIF.
Denial of service in OpenImageIO's PSD reader allows a crafted PSD file carrying an invalid color_mode value to index beyond the fixed color-mode tables, producing a global out-of-bounds read and potentially a bogus allocation that crashes the reading process. The exposure is narrow: the raw path is only reachable when the non-default oiio:RawColor or psd:RawData option is explicitly enabled, and an attacker must get a target application or automated pipeline to open the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, score 5.5, CWE-125), so impact is availability-only with no confidentiality or integrity effect. No public exploit has been identified at time of analysis, and vendor-released fixes exist in 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.
A heap out-of-bounds read in the OpenImageIO PSD reader can crash any application that processes a crafted indexed Photoshop (PSD) file while the non-default oiio:rawcolor or psd:rawdata option is enabled. The flaw affects OpenImageIO builds prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, where a PSD whose transparency metadata yields fewer stored channel buffers than the advertised channel count causes PSDInput::interleave_row() to read past the end of channel_buffers. Exploitation is local with required user interaction (the victim must supply or open the malicious file), the vulnerable rawcolor/rawdata path is not the default configuration, and impact is limited to a denial-of-service crash of the processing process, with no code execution or data disclosure reported; no public exploit has been identified at time of analysis, and CVSS 5.5 (A:H, C:N/I:N) reflects the availability-only, non-default-path nature of the issue.
Stack-based buffer overflow in OpenImageIO's Cineon image reader (CineonInput::open()) lets a crafted .cin file that declares more than the format's maximum of eight channels overwrite stack pointers and corrupt adjacent memory, crashing the application that processes it. Exploitation requires the victim or an automated pipeline to open the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H, 6.1), so it cannot be triggered remotely without inducing file ingestion; the assessed impact is denial of service with only low integrity risk and no confidentiality loss. No public exploit identified at time of analysis and the issue is not in CISA KEV; vendor fixes shipped in OpenImageIO 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1.
Heap out-of-bounds read in OpenImageIO's IFF image reader (src/iff.imageio/iffinput.cpp, IffInput::readimg()) affects all releases prior to 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1, allowing a caller that opens a crafted uncompressed 16-bit IFF file containing a z-buffer channel to trigger a crash or leak adjacent heap contents into the decoded image output. The flaw is an allocation/stride mismatch: the temporary scanline buffer is sized from m_header.rgba_count while the subsequent memcpy uses m_header.pixel_bytes(), whose stride also counts z-buffer bytes, producing an oversized copy. Exploitation requires local, user-initiated parsing of the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, 6.1) with no privileges needed but no remote zero-interaction path; no public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS/KEV data were not provided. Vendor-released patches exist in versions 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1.
An out-of-bounds read in Zephyr RTOS's gPTP (IEEE 802.1AS) announce-qualification routine lets an unauthenticated attacker with layer-2 adjacency to a vulnerable device send a single crafted Announce frame that drives the stack about 2 KB past the end of the received network buffer, potentially faulting the networking RX thread and causing a denial of service. The flaw affects only builds that enable the opt-in, experimental CONFIG_NET_GPTP option used in TSN/AVB deployments (Zephyr 1.13.0 up to before 4.4.2 per EUVD); default configurations are not vulnerable, and because gPTP frames go to a non-routed link-local multicast address, internet or routed exploitation is not possible. The impact is bounded by the assessed CVSS 3.1 vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, and no public exploit has been identified at time of analysis.
An out-of-bounds read in the Zephyr RTOS gPTP (IEEE 802.1AS) Ethernet layer lets an attacker on the same link crash-free but silently expose memory contents: a truncated Ethernet frame with ethertype 0x88F7 and fewer than 34 bytes of payload is accepted by gptp_handle_msg(), which dereferences a gPTP header pointer that extends past the received data and then retains the short packet for later state-machine parsing. Affected are Zephyr releases from 1.13.0 up to (but not including) 4.4.2 built with CONFIG_NET_GPTP on an interface configured as a gPTP port; no authentication or user interaction is required (PR:N/UI:N), though exploitation is limited by the adjacent-only vector and the requirement for a link that can deliver sub-minimum frames (for example the native_sim TAP driver or a MAC that accepts undersized frames). The impact is read-only and low (CVSS 3.1 base 3.1, C:L/I:N/A:N): under the default fixed-size buffer allocator only stale recycled buffer contents within the 128-byte fragment are disclosed, while a genuine out-of-bounds read requires the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; an upstream fix commit and vendor advisory are available.
Privileged users inside a guest running on a Q35/KVM QEMU virtual machine can abuse the VAPIC setup hypercall in hw/i386/vapic.c to position a writable RAM alias over locked SMRAM, bypassing the Q35 chipset's D_LCK protection and injecting code into System Management Mode memory - the highest-privilege execution context on the platform. The flaw is an out-of-bounds write (CWE-787) scored 6.7 under CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H: it is local to the guest, requires an already root-equivalent account there, and does not affect non-Q35 machine types or non-KVM configurations, which substantially narrows realistic exposure. No public exploit code was identified at time of analysis and there is no confirmed active exploitation, but the SMM-level payoff makes it attractive as the final step in a guest-to-firmware escalation chain.
Integer overflow in the File Operation component of Synology DiskStation Manager (DSM) allows remote authenticated users to trigger a limited denial-of-service condition against affected NAS appliances. Only systems running DSM versions prior to 7.2.1-69057-10, 7.2.2-72806-7, or 7.3.2-86009-2 are affected; the vulnerability requires a valid DSM account with rights to invoke File Operation, matching the CVSS vector's PR:L (authenticated) rating. Impact is confined to low availability loss with no confidentiality or integrity effect, no public exploit code has been identified at time of analysis, and EPSS/KEV data do not indicate active exploitation, making this a low-priority issue despite the network attack vector.
An out-of-bounds read in GPAC's RTP depacketizer lets unauthenticated remote attackers crash or partially disclose memory by delivering a crafted 3GPP timed-text (TTXT) RTP payload with an oversized advertised length. The flaw lives in gf_rtp_parse_ttxt() in src/ietf/rtp_depacketizer.c and affects GPAC 26.08-DEV and earlier builds prior to abi-16.26; exploitation requires the target to be acting as an RTP receiver/depacketizer rather than simply parsing a local file. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV), so this is a genuine but moderate-severity memory-safety defect whose practical reach depends on GPAC being deployed in an RTP-consuming configuration.
Integer overflow in the JBIG2 code-table parser (JBIG2Stream::readCodeTableSeg) of Freedesktop Poppler 26.07.0 allows a remote attacker to crash or destabilize the rendering process by supplying a crafted PDF that embeds a malicious JBIG2 image stream. The flaw is reachable without authentication, but requires the victim to open the document or have a batch tool such as pdftoppm or pdfimages process it, and the independent assessment limits realistic impact to denial of service (integrity and confidentiality are unaffected). Publicly available exploit code exists (a write-up and PoC linked from the CVE references), and the CISA KEV catalog does not list this CVE, so it is a low-to-moderate, non-urgent memory-safety issue rather than a confirmed actively exploited threat.
Integer overflow in Freedesktop Poppler 26.07.0's SampledFunction::SampledFunction (poppler/Function.cc) allows unauthenticated remote attackers to crash PDF-rendering applications by supplying a crafted PDF with an oversized BitsPerSample value, resulting in an availability-only denial of service. Exploitation requires a victim to open or render the malicious file (UI:P/UI:R), and publicly available exploit code exists; the issue is not confirmed as actively exploited in CISA KEV. With a CVSS 4.0 base score of 2.1 and an independent CVSS 3.1 assessment of AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L, the risk is low and confined to availability with no demonstrated confidentiality or integrity impact.
Heap memory corruption in snappy-java 1.1.10.8 and earlier allows remote attackers to write attacker-influenced bytes past the bounds of the output array when an application decompresses untrusted compressed data through the typed Snappy.uncompress*Array APIs (such as uncompressIntArray, uncompressFloatArray, or uncompressDoubleArray), which size their result array using the uncompressed length divided by element size while forwarding the undivided length to the native JNI layer. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, C:N/I:L/A:L) no authentication or user interaction is needed, but exploitation is conditional: the consuming application must expose the typed decompression path to attacker-controlled input, and applications that only use the generic byte[] uncompress path are not exposed. Impact is currently rated Low integrity and Low availability (heap corruption and crash) with no confirmed confidentiality loss or demonstrated code execution, and no public exploit was identified at time of analysis; this is a genuine memory-corruption flaw but a moderate, not top-tier, priority, and no vendor-released fixed version is identified in the available data.
Imager::File::PNG versions from 1.003 before 1.004 for Perl write past the end of the row buffer reading a PNG with a tRNS transparency chunk in read_direct8. With a tRNS chunk, read_direct8() adds an alpha channel to the image it creates but still sizes the row buffer from the original channel count. libpng expands the transparency into that extra channel, so png_read_row() fills one channel more than the buffer holds, at one byte per sample, and writes width bytes past the end of the allocation. Palette images go to read_paletted() and 16-bit images to read_direct16(), which sizes its buffer from png_get_rowbytes() and allocates enough for the expanded row. The same reader ships bundled in the Imager distribution. Reading an attacker-supplied PNG through Imager->read() corrupts the heap, which can crash the process.
Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process.
Heap out-of-bounds read in the PoDoFo C++ PDF library (versions 1.0.0 through 1.1.0) lets a crafted PDF containing an Indexed color-space image cause the library to read past the end of its palette lookup buffer. An attacker must convince a victim to hand the malicious PDF to an application built on the affected library and have that application decode or render the embedded Indexed image; no authentication is required (CVSS 4.0 vector PR:N, AV:L, UI:P), and the practical impact is dominated by a process crash leading to denial of service, with only adjacent heap bytes potentially disclosed rather than targeted secret exfiltration. Exploitation yields a limited confidentiality gain and a high availability impact; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The flaw is fixed in PoDoFo 1.1.1.
An out-of-bounds read in OpenImageIO's BMP reader allows a crafted palette BMP to crash any process that decodes it, causing denial of service. Affected are versions prior to 3.0.16.0 and 3.1.11.0: a malformed file whose DIB header sets the palette flag but supplies an empty color table, combined with RLE4 or RLE8 compression, drives BmpInput::read_native_scanline into an invalid palette lookup. Exploitation requires the victim to process the attacker-supplied image (for example via oiiotool or an application linked against OpenImageIO), making the realistic risk concentrated in automated or batch image-ingestion pipelines; no public exploit identified at time of analysis, and CISA KEV does not list this issue.
Memory disclosure in Google Chrome prior to 153.0.8010.52 allows a local attacker to read out-of-bounds data through the browser's DataTransfer implementation, with the sandbox-crossing scope change (S:C) in the CVSS vector indicating the leaked memory can originate outside the renderer process rather than from within the attacker's own context. Per the assessed vector (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N, base 6.3) exploitation requires the attacker to already be running a local program on the victim's machine and to use social engineering to obtain user interaction, and it produces only confidentiality impact with no integrity or availability effect, so this is an information-disclosure bug rather than a sandbox escape or code-execution primitive. There is no public exploit code identified at time of analysis and the issue is not confirmed actively exploited (it is not in CISA KEV); Google has shipped version 153.0.8010.52, which resolves the flaw.
Denial of service in applications using the MongoDB C Driver's libbson library can be triggered by crafted BSON input with a zero document-length field, which causes an integer underflow (CWE-191) and a heap out-of-bounds read that crashes the process. The CVSS v4.0 vector indicates remote, unauthenticated exploitation (AV:N/PR:N/UI:N), but the vulnerability only affects code paths that pass untrusted BSON to bson_new_from_buffer(), and impact is limited to a process crash with no data disclosure or code execution. No public exploit code or active exploitation (CISA KEV) was identified in the provided intelligence.
Denial of service in rabbitmq-c (librabbitmq) versions prior to 0.16.0 lets an attacker-controlled or on-path AMQP server crash a connecting client during the login handshake by sending an undersized HEADER or METHOD frame. The malformed frame triggers an unsigned size_t underflow in the frame parser that defeats downstream bounds checks and causes an out-of-bounds read, terminating the client process. Per the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5) the impact is purely availability, requiring the victim to initiate a connection (UI:R); no public exploit identified at time of analysis, and TLS with proper certificate validation neutralizes the on-path variant.
Spoofed or injected ICMP echo replies can steer mport's mirror-latency selection toward an attacker-chosen mirror and, if the reply carries IP options, shift the parsed ICMP header past the hardcoded offset used by ping() in libmport/ping.c, causing an out-of-bounds read. The flaw affects MidnightBSD mport releases prior to 2.7.8 and is only reachable by an unauthenticated attacker on the same adjacent network segment who can place visible ICMP traffic on-path while an mport client is actively probing mirrors (assessed CVSS:3.1 AV:A/AC:H/PR:N/UI:N/C:N/I:L/A:L; CVSS 4.0 base 2.3). Impact is low and confined to the transient probing window; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released version 2.7.8 as the fix.
In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.
In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].
In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.
In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.
In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.
In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.
In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix out-of-bounds access in mmio copy helpers mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.
In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix max_qid race between configfs and controller allocation The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in sbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.
In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] <TASK> [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] </TASK> [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.
In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in <uapi/linux/atmdev.h> as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.
Out-of-bounds write in vgmstream (through r2117) lets an attacker corrupt heap memory when a crafted EA SCHl audio file is decoded, triggered inside vadpcm_read_coefs_be in src/coding/vadpcm_decoder.c via a manipulated coefficient entry/entries count. The vulnerable code path is reached from any application embedding the library - media players and game-audio converters that use vgmstream - but exploitation requires the victim to open or load the malicious file (passive user interaction); there is no network service to hit and no public exploit identified at time of analysis. The vendor rates it CVSS 4.0 5.3, while this assessment maps it to CVSS 3.1 AV:L/AC:L/PR:N/UI:R with Low confidentiality, integrity and availability impact and no demonstrated path to code execution.
Memory corruption in Qualcomm Snapdragon rear sensor IOCTL handling allows a local high-privileged attacker to execute code, tamper with data, or cause denial of service on affected devices. Exploitation requires local access and high privileges (PR:H) to invoke the rear (camera) sensor IOCTL, typically only reachable from a privileged camera HAL or system service; no user interaction is needed, but crafted parameters must be supplied to the vulnerable interface. No public exploit identified at time of analysis, and the required high privilege level narrows the practical attacker population.
Memory corruption in Qualcomm Snapdragon platforms allows an attacker who already holds a low-privileged local foothold on the device to corrupt memory by feeding oversized input into a copy routine that exceeds expected allocation limits, giving high impact to confidentiality, integrity, and availability of the affected component. The flaw is not remotely exploitable on its own: exploitation requires local access with low privileges (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) - for example a malicious or compromised application able to reach the vulnerable code path - and no user interaction is needed. No public exploit code has been identified at time of analysis, and no CISA KEV listing or EPSS score was provided; the referenced Qualcomm September 2026 security bulletin is the authoritative source for the specific affected chipsets and fixed versions.
Heap buffer overflow in an unspecified Ubuntu utility's duplicate_legacy_root_dir function can lead to high confidentiality, integrity, and availability impact when a local attacker convinces a user or automated job to process a crafted input, such as a malicious filesystem image or legacy-format file. The assessed CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates local access, no privileges required, and user interaction as the primary limiting factor, but the exact product, affected versions, and trigger condition are unconfirmed due to the record lacking product name, CWE, EPSS, KEV, and POC data. No public exploit identified at time of analysis.
Heap buffer overflow in the FAT-filesystem parsing code paths identified as _init_fats and fat_table_read - most likely the libparted FAT module used by GNU Parted and its fatresize component - allows memory corruption when a malformed FAT volume is parsed. The issue is local in scope (AV:L) and requires user interaction (UI:R): a victim must open a crafted disk/partition image or insert a removable device whose FAT table has been manipulated, and a parsing path (resize, inspection, or a mount helper such as udisks auto-mount handling) must actually read that volume. The assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H indicates unauthenticated local attackers can achieve high confidentiality, integrity, and availability impact if the bug is reliably triggered, though whether the overflow yields code execution rather than a crash is unproven and impact is amplified only if the parser runs with elevated privileges. No CISA KEV entry and no public exploit code have been identified - no public exploit identified at time of analysis - and no EPSS score was supplied; the exact affected package, version range, and default-configuration reachability remain unconfirmed from the available data.
An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.
Opening a specially crafted BIFS or LASeR scene file in GPAC 26.08-DEV can trigger a use-after-free in the scene-graph command handler, crashing the application. Only local exploitation is possible: the victim must load attacker-supplied media in a vulnerable pre-abi-16.24 build, there is no network-reachable trigger, and impact is limited to availability (denial of service) with no confidentiality or integrity effect. Publicly available exploit code exists (referenced PoC archive on GitHub), and the underlying flaw is remediated by the upstream fix released in abi-16.24 (commit e34f4ba); despite the public PoC this is a low-priority, low-real-risk issue given the local, user-interaction-dependent attack path.
Stack-based buffer overflow in the Dell Update Package (DUP) Framework, affecting all versions prior to 26.07.03, allows an unauthenticated attacker who can reach the affected component from an adjacent network segment (AV:A, PR:N, UI:N) to corrupt stack memory and potentially achieve code execution or crash the process. Dell scores this 6.5 with CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (availability-only), whereas independent assessment rates the impact as complete loss of confidentiality, integrity and availability (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), which aligns with the description's statement that the flaw can lead to remote execution; the practical constraint in both readings is the adjacency requirement rather than internet-wide reachability. No CISA KEV entry and no public exploit code were identified at time of analysis, and Dell has published DSA-2026-417 with a fixed release (26.07.03).
Heap-based buffer overflow in GPAC 26.07.0's Remotery-style WebSocket remote-monitoring handler (rmt_client_handle_ws_frame in src/utils/rmt_ws.c) lets remote attackers corrupt heap memory by sending a WebSocket frame whose advertised payload_size is manipulated, since the value is trusted when computing how much extra data to read. The CVSS 4.0 score is 6.9 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N and the E:P exploit-maturity flag; an independent assessment rates the memory-safety consequence more severely (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H), reflecting that availability impact can be complete once the interface is reached. Publicly available exploit code exists - a Python PoC (poc_rmt_ws_malicious_frame.py) is attached to the upstream GitHub issue - but there is no confirmation of active exploitation (no CISA KEV listing). The practical limiting factor is exposure: the rmt_ws handler must be compiled in, enabled, and network-reachable, which is not the default posture for typical GPAC/MP4Box usage.
Heap use-after-free in the HDF5 library (The HDF Group, all versions before 2.3.0) is triggered when an application such as h5dump reads a dataset whose compound datatype contains floating-point members, allowing a crafted .h5 file to crash the parsing process and, depending on heap layout and allocator behaviour, potentially corrupt memory further. Exploitation requires the victim to open a malicious file locally (local vector, mandatory user interaction, no authentication needed), so it is not remotely reachable on its own. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor's own CVSS 4.0 base of 4.6 aligns with the independent assessment that the reliably demonstrated impact is a crash rather than proven code execution.
An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.
In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.
An out-of-bounds read in the HTTP Cache-Control response header parser of the QtNetwork module lets a hostile or compromised HTTP server crash 64-bit client applications built on Qt 6.0.0-6.8.8 or 6.9.0-6.11.1 that use QNetworkAccessManager. The trigger is an excessively large Cache-Control header value returned to the requesting client; because the over-read is read-only, the outcome is limited to a denial of service (application crash) with no information disclosure and no code execution, and only the client side of the connection is affected - 32-bit builds are not affected. No public exploit code has been identified at time of analysis, and exploitation is not on-demand against an arbitrary target: the victim application must be induced to connect to an untrusted, attacker-controlled, or compromised server (reflected as AT:P in the CVSS 4.0 vector), which keeps real-world risk at a low-to-moderate level despite the presence of RCE and Information Disclosure tags in some feeds.
In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)
A heap-based buffer overflow in the Samsung Escargot JavaScript engine is reachable when a crafted bytecode-cache file is parsed, driven by an integer wraparound (CWE-190) in the string-table length handling inside CodeCacheReader::loadStringTable. Exploitation requires local write access to the engine's bytecode-cache directory (CVSS 5.5, AV:L/PR:L), and the impact is limited to availability - a crash or memory-corruption-induced denial of service with no confidentiality or integrity loss. No public exploit code or CISA KEV listing was identified at time of analysis, and the upstream fix (Samsung PR #1650) adds a bounds check rejecting any maxLength above STRING_MAXIMUM_LENGTH.
An out-of-bounds read in the ARP filter import handler (filter_arp_put_file.cgi) of Netcore NR255-V firmware 1.5.130703 lets an attacker who can reach the router's web management interface and supply a malformed, non-null-terminated string cause the string-handling API to read past the end of an allocated buffer, exposing adjacent process memory in the response. The flaw is rated CVSS 5.3 (CVSS:4.0/AV:N/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L), indicating a network-reachable, low-privilege issue with limited confidentiality and availability impact only — there is no confirmed integrity impact, no CISA KEV listing, and no confirmed public exploit code; the only public material is a VulnCheck advisory plus a third-party GitHub technical reference whose exploit content is unverified.
An integer overflow in Google Chrome's Compositing component (fixed in 153.0.8010.47) lets a remote attacker leak cross-origin data by getting a victim to open a crafted HTML page. Exploitation requires user interaction (the victim must load the page) but no authentication or elevated privileges, and the impact is limited to confidentiality - integrity and availability are unaffected per the CVSS vector. There is no public exploit code or CISA KEV listing at time of analysis, and the CVSS base score is only 4.3, so this is a browser-patching hygiene issue rather than an emergency incident response trigger.
Google Chrome for Android versions prior to 153.0.8010.47 contain an out-of-bounds read in the WebGL rendering path that allows a remote attacker to leak memory from outside the browser sandbox by luring a victim into opening a crafted HTML page. Google labels the Chromium security severity as Critical, while the published CVSS 3.1 base score is a comparatively modest 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) because the flaw yields a limited confidentiality leak rather than code execution or data modification. A vendor patch is available, and no public exploit code or CISA KEV entry was identified at the time of analysis.
A malicious or compromised IMAP server can trigger an out-of-bounds read in the IMAP response parser by sending an untagged '* ID' response, crashing Thunderbird. The affected parsing path is reachable before authentication. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
A maliciously constructed IMAP line could cause an out-of-bounds buffer read. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
Authenticated attackers holding Admin privileges on HPE Networking EdgeConnect SD-WAN Gateways can send a crafted request to an API endpoint and trigger a classic buffer overflow (CWE-120), potentially achieving arbitrary command execution on the appliance's underlying operating system. ENISA EUVD lists affected builds across the 9.4.x, 9.5.x, 9.6.x and 9.7.x release branches, with the HPE advisory as the sole authoritative reference. No public exploit code and no CISA KEV entry were reported at time of analysis, and the vendor's 5.5 CVSS score omits any confidentiality impact despite the description claiming full OS-level command execution.
A buffer overflow in the web-based management interface of HPE Networking EdgeConnect SD-WAN Gateways allows an authenticated administrator to crash or destabilize the appliance, producing a denial-of-service condition. All maintenance branches 9.4.0.0 through 9.4.8.2, 9.5.0.0 through 9.5.8.1, 9.6.0.0 through 9.6.3.1, and 9.7.0.0 are affected per ENISA EUVD tracking. The CVSS base of 5.5 with PR:H reflects that high administrative privileges are required, so this is not an unauthenticated remote outage; no public exploit code or CISA KEV listing was identified at time of analysis.
A buffer overflow in a system service of the underlying operating system on HPE Networking EdgeConnect SD-WAN Gateways allows an unauthenticated attacker who already sits on an adjacent network segment to crash the affected service, temporarily disrupting SD-WAN and branch network operations. All editions of the 9.4.x (up to 9.4.8.2), 9.5.x (up to 9.5.8.1), 9.6.x (up to 9.6.3.1) and 9.7.0.0 releases are listed as affected by the vendor. The impact is degraded availability rather than confidentiality or code execution, exploitation requires high attack complexity, and no public exploit code or CISA KEV entry was identified at time of analysis.
A buffer overflow in the underlying operating system of HPE Networking EdgeConnect SD-WAN Gateways lets an unauthenticated remote attacker send specially crafted packets to an affected service and corrupt its memory. Rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L, CWE-120), successful exploitation degrades the integrity and availability of the gateway service without exposing confidential data. No CISA KEV listing and no public exploit code were identified in the supplied intelligence, and no EPSS score was provided, so exploitation is currently assessed as opportunistic rather than confirmed in the wild.
An out-of-bounds write in the Android kernel GNSS link driver lets a local process that already holds System execution privileges corrupt kernel memory and escalate to kernel-level code execution. The defect (CWE-787) is a missing bounds check in link_load_gnss_image() in link_device.c, requires no user interaction, and is addressed through Google's September 2026 Android/Pixel security bulletin. No public exploit code or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds read in the Pixel-specific physmem_extmem driver (physmem_extmem_linux.c) of the Android kernel lets a local process with low privileges read kernel memory that was never initialized, exposing potentially sensitive data. No user interaction or elevated execution privileges are required, and the impact is limited to confidentiality (CVSS 5.5, AV:L/PR:L/C:H). The issue is addressed in the September 2026 Android/Pixel security bulletin; no public exploit code or CISA KEV listing was identified at the time of analysis.
An out-of-bounds write in the Android kernel, caused by a missing bounds check, allows an attacker who already holds System-level execution privileges on a device to corrupt kernel memory and escalate to full kernel/root privileges. The flaw is reachable only with local access (AV:L, PR:H) and requires no user interaction, and the associated CVSS score of 6.7 reflects high integrity, confidentiality and availability impact rather than ease of reach. No public exploit code or CISA KEV active-exploitation listing was provided in the available intelligence, so this is currently assessed as a patch-priority local privilege-escalation bug rather than a known exploited threat.
A missing bounds check in multiple locations of Android kernel code allows a local attacker who already holds System execution privileges to trigger an out-of-bounds write and escalate to higher, kernel-level privileges on affected devices. Google Android builds that ship the impacted kernel code are affected, with fixes published through the September 2026 Pixel/Android security bulletin. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 6.7 score reflects the demanding high-privilege prerequisite rather than any remote reachability.
Out-of-bounds write in the Android kernel lets a local attacker who already holds System-level execution privileges corrupt memory and escalate to full kernel/root code execution without any user interaction. Devices running Android builds that have not yet adopted the September 2026 (2026-09-01) security patch level are affected, with Google rating the flaw High at CVSS 6.7. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS score was supplied with this data.
An out-of-bounds read in the Android kernel driver routine gf_algo_get_cached_dump_data (gf_algo.c) lets a locally positioned attacker with limited privileges read past the end of a buffer and leak kernel memory contents, with no user interaction required. Pixel builds that ship the vulnerable gf_ driver are affected, and the September 2026 Android/Pixel security bulletin provides the fix. Neither public exploit code nor a CISA KEV entry was present in the supplied intelligence, and no EPSS score was provided, so active exploitation is unconfirmed and the practical threat at time of analysis is a local, post-compromise or malicious-app information leak.
Memory corruption in the Android Trusted Execution Environment (TEE) allows a local attacker who already holds System execution privileges to escalate privileges within the secure world by supplying improperly validated input to an affected secure-world interface. The flaw is local-only (AV:L), requires high pre-existing privileges (PR:H), and needs no user interaction (UI:N), yielding high confidentiality, integrity, and availability impact if the corrupted trusted application is reached; Google rates it 6.7 (Medium). Risk is tempered by the significant foothold required, the local-only attack surface, and the low EPSS score (0.11%, 2nd percentile); no public exploit code has been identified and the flaw is not listed in CISA KEV, with fixes delivered in the Pixel security bulletin dated 2026-09-01.
Let me synthesize. CVE-2026-56923: Android kernel TIPC virtio driver (tipc_virtio_dev.c) handle_unmap_req race condition memory corruption, local EoP. CVSS 3.1: AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H → 6.4. Note PR:H which is odd for a local privilege escalation "with no additional execution privileges needed" — the description says no additional execution privileges needed. Hmm, the CVSS says PR:H. There's a conflict: description says local EoP with no additional execution privileges needed (implying PR:N or PR:L?), while CVSS vector says PR:H. This is a data conflict worth noting in confidence_notes and risk_assessment. Actually Android's kernel CVEs for local EoP typically are AV:L/AC:H/PR:H/UI:N in their bulletins... Actually Android uses PR:H sometimes? Hmm. Let me note the conflict: description claims "no additional execution privileges needed" but vector shows PR:H (high privileges required), which typically means the attacker already needs elevated privileges — contradictory for an EoP. State explicitly. Product name: "Android Kernel" — 2 words. Or "TIPC Virtio Driver". Primary product per CPE: google:android. I'd say "Android Kernel". Tags: Privilege Escalation, Buffer Overflow, Google, Race Condition. Buffer Overflow mislabeled? The CWE is race condition/memory corruption. Hmm — "Buffer Overflow" tag is arguably a mislabeled tag since CWE-362 race condition and description says memory corruption not buffer overflow. But memory corruption could involve buffer overflow. I'd be moderately confident... The instructions say only emit flag when clearly wrong and verifiable. Memory corruption due to race condition — buffer overflow is a specific subclass. It's arguably mislabeling. I could flag it with low/medium confidence. Hmm. I think I'll flag it as mislabeled_tag with medium confidence since the CVE is a race condition leading to memory corruption, no buffer overflow specified. Actually careful — race conditions can cause buffer overflows (TOCTOU). Risky.
In libsmpp35 from 0.1.0 through 1.8.0 out of bound read issue was found in the at smpp34_unpack() function via attacker controlled SMPP PDUs, leading to memory corruption.
In osmo-bsc from 1.0.1 through 1.14.1 a heap based buffer overflow issue was found in the ipaccess_proxy_read_msg() function via IPA frame lengths.
In osmo-ggsn 1.14.0 an out of bounds write issue was found in the gtp_decode_pdp_ctx() function through the PDP context GSN-Address sub-field, leading to memory corruption.
Heap-based out-of-bounds write in the PJSIP pjmedia AVI player (pjproject 2.17 and earlier) lets a crafted AVI file overwrite memory beyond a frame buffer when an application plays the file or pulls its frames. The buffer capacity is derived from the video dimensions declared in the file, while the copy length is taken from the file's own chunk header, so a malicious header produces an attacker-controlled write; the protection that would normally catch this is a pj_assert() that is compiled out of production release builds. The issue is local and file-driven, requiring the victim to open the media (CVSS v3.1 AV:L/UI:R, PR:N per the assessed vector), with crash-level impact for ordinary local playback and full memory corruption for applications that ingest untrusted AVI from relays, transcoders or user uploads; no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and no fixed release version is available as of this review.
An integer-wraparound in Cockpit's do_lastlog() login-accounting routine on ILP32 (32-bit) builds allows a low-privileged but authenticated local user holding an administrator-provisioned abnormally large UID to read and modify other users' lastlog records, producing low confidentiality and low integrity impact (CVSS 3.1 base 3.6, AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N). Exploitation requires a 32-bit build, a deliberately created large-UID account, and local access to the host; 64-bit LP64 builds do not overflow and are unaffected, and no public exploit code has been identified at time of analysis.
Heap out-of-bounds read in libheif prior to 1.23.2 lets an application that builds inline-mask region metadata through the library's writer API leak adjacent heap memory or crash. Specifically, heif_region_item_add_region_inline_mask_data() stored a caller-supplied mask buffer without verifying that mask_data_len equals ceil(width*height/8); a later heif_region_get_mask_image() render derives the number of bytes to read from the region geometry, so an undersized buffer causes the reader to copy bytes past the end of the allocation into the returned monochrome mask image. The file-parsing/decode path validates the canonical mask size and is explicitly not vulnerable, so merely opening a crafted HEIF/AVIF file does not trigger the bug; exploitation requires a local program in which attacker-influenced geometry and mask data disagree, consistent with the assessed vector AV:L/AC:H/PR:N/UI:N (CVSS 4.0). There is no confirmed active exploitation (no CISA KEV listing), and no public exploit code was identified at time of analysis; the issue is a genuine but low-priority memory-safety defect rather than an emergency, and version 1.23.2 fixes it.
Denial of service in OpenImageIO versions prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1 occurs when the library processes a truncated TGA file while writing GIF output, triggering a signed 32-bit integer overflow in GifSplitPalette() that leads to an out-of-bounds read (CWE-125) and a process crash. The CVSS v3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) indicates the attacker is unauthenticated (PR:N) but requires local access and user interaction, with no remote or unauthenticated network trigger. No public exploit code or active exploitation has been identified; this is a low-priority hardening issue for workflows that transcode untrusted images to GIF.
Denial of service in OpenImageIO's PSD reader allows a crafted PSD file carrying an invalid color_mode value to index beyond the fixed color-mode tables, producing a global out-of-bounds read and potentially a bogus allocation that crashes the reading process. The exposure is narrow: the raw path is only reachable when the non-default oiio:RawColor or psd:RawData option is explicitly enabled, and an attacker must get a target application or automated pipeline to open the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, score 5.5, CWE-125), so impact is availability-only with no confidentiality or integrity effect. No public exploit has been identified at time of analysis, and vendor-released fixes exist in 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.
A heap out-of-bounds read in the OpenImageIO PSD reader can crash any application that processes a crafted indexed Photoshop (PSD) file while the non-default oiio:rawcolor or psd:rawdata option is enabled. The flaw affects OpenImageIO builds prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, where a PSD whose transparency metadata yields fewer stored channel buffers than the advertised channel count causes PSDInput::interleave_row() to read past the end of channel_buffers. Exploitation is local with required user interaction (the victim must supply or open the malicious file), the vulnerable rawcolor/rawdata path is not the default configuration, and impact is limited to a denial-of-service crash of the processing process, with no code execution or data disclosure reported; no public exploit has been identified at time of analysis, and CVSS 5.5 (A:H, C:N/I:N) reflects the availability-only, non-default-path nature of the issue.
Stack-based buffer overflow in OpenImageIO's Cineon image reader (CineonInput::open()) lets a crafted .cin file that declares more than the format's maximum of eight channels overwrite stack pointers and corrupt adjacent memory, crashing the application that processes it. Exploitation requires the victim or an automated pipeline to open the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H, 6.1), so it cannot be triggered remotely without inducing file ingestion; the assessed impact is denial of service with only low integrity risk and no confidentiality loss. No public exploit identified at time of analysis and the issue is not in CISA KEV; vendor fixes shipped in OpenImageIO 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1.
Heap out-of-bounds read in OpenImageIO's IFF image reader (src/iff.imageio/iffinput.cpp, IffInput::readimg()) affects all releases prior to 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1, allowing a caller that opens a crafted uncompressed 16-bit IFF file containing a z-buffer channel to trigger a crash or leak adjacent heap contents into the decoded image output. The flaw is an allocation/stride mismatch: the temporary scanline buffer is sized from m_header.rgba_count while the subsequent memcpy uses m_header.pixel_bytes(), whose stride also counts z-buffer bytes, producing an oversized copy. Exploitation requires local, user-initiated parsing of the malicious file (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, 6.1) with no privileges needed but no remote zero-interaction path; no public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS/KEV data were not provided. Vendor-released patches exist in versions 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1.
An out-of-bounds read in Zephyr RTOS's gPTP (IEEE 802.1AS) announce-qualification routine lets an unauthenticated attacker with layer-2 adjacency to a vulnerable device send a single crafted Announce frame that drives the stack about 2 KB past the end of the received network buffer, potentially faulting the networking RX thread and causing a denial of service. The flaw affects only builds that enable the opt-in, experimental CONFIG_NET_GPTP option used in TSN/AVB deployments (Zephyr 1.13.0 up to before 4.4.2 per EUVD); default configurations are not vulnerable, and because gPTP frames go to a non-routed link-local multicast address, internet or routed exploitation is not possible. The impact is bounded by the assessed CVSS 3.1 vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, and no public exploit has been identified at time of analysis.
An out-of-bounds read in the Zephyr RTOS gPTP (IEEE 802.1AS) Ethernet layer lets an attacker on the same link crash-free but silently expose memory contents: a truncated Ethernet frame with ethertype 0x88F7 and fewer than 34 bytes of payload is accepted by gptp_handle_msg(), which dereferences a gPTP header pointer that extends past the received data and then retains the short packet for later state-machine parsing. Affected are Zephyr releases from 1.13.0 up to (but not including) 4.4.2 built with CONFIG_NET_GPTP on an interface configured as a gPTP port; no authentication or user interaction is required (PR:N/UI:N), though exploitation is limited by the adjacent-only vector and the requirement for a link that can deliver sub-minimum frames (for example the native_sim TAP driver or a MAC that accepts undersized frames). The impact is read-only and low (CVSS 3.1 base 3.1, C:L/I:N/A:N): under the default fixed-size buffer allocator only stale recycled buffer contents within the 128-byte fragment are disclosed, while a genuine out-of-bounds read requires the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; an upstream fix commit and vendor advisory are available.
Privileged users inside a guest running on a Q35/KVM QEMU virtual machine can abuse the VAPIC setup hypercall in hw/i386/vapic.c to position a writable RAM alias over locked SMRAM, bypassing the Q35 chipset's D_LCK protection and injecting code into System Management Mode memory - the highest-privilege execution context on the platform. The flaw is an out-of-bounds write (CWE-787) scored 6.7 under CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H: it is local to the guest, requires an already root-equivalent account there, and does not affect non-Q35 machine types or non-KVM configurations, which substantially narrows realistic exposure. No public exploit code was identified at time of analysis and there is no confirmed active exploitation, but the SMM-level payoff makes it attractive as the final step in a guest-to-firmware escalation chain.
Integer overflow in the File Operation component of Synology DiskStation Manager (DSM) allows remote authenticated users to trigger a limited denial-of-service condition against affected NAS appliances. Only systems running DSM versions prior to 7.2.1-69057-10, 7.2.2-72806-7, or 7.3.2-86009-2 are affected; the vulnerability requires a valid DSM account with rights to invoke File Operation, matching the CVSS vector's PR:L (authenticated) rating. Impact is confined to low availability loss with no confidentiality or integrity effect, no public exploit code has been identified at time of analysis, and EPSS/KEV data do not indicate active exploitation, making this a low-priority issue despite the network attack vector.
An out-of-bounds read in GPAC's RTP depacketizer lets unauthenticated remote attackers crash or partially disclose memory by delivering a crafted 3GPP timed-text (TTXT) RTP payload with an oversized advertised length. The flaw lives in gf_rtp_parse_ttxt() in src/ietf/rtp_depacketizer.c and affects GPAC 26.08-DEV and earlier builds prior to abi-16.26; exploitation requires the target to be acting as an RTP receiver/depacketizer rather than simply parsing a local file. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV), so this is a genuine but moderate-severity memory-safety defect whose practical reach depends on GPAC being deployed in an RTP-consuming configuration.
Integer overflow in the JBIG2 code-table parser (JBIG2Stream::readCodeTableSeg) of Freedesktop Poppler 26.07.0 allows a remote attacker to crash or destabilize the rendering process by supplying a crafted PDF that embeds a malicious JBIG2 image stream. The flaw is reachable without authentication, but requires the victim to open the document or have a batch tool such as pdftoppm or pdfimages process it, and the independent assessment limits realistic impact to denial of service (integrity and confidentiality are unaffected). Publicly available exploit code exists (a write-up and PoC linked from the CVE references), and the CISA KEV catalog does not list this CVE, so it is a low-to-moderate, non-urgent memory-safety issue rather than a confirmed actively exploited threat.
Integer overflow in Freedesktop Poppler 26.07.0's SampledFunction::SampledFunction (poppler/Function.cc) allows unauthenticated remote attackers to crash PDF-rendering applications by supplying a crafted PDF with an oversized BitsPerSample value, resulting in an availability-only denial of service. Exploitation requires a victim to open or render the malicious file (UI:P/UI:R), and publicly available exploit code exists; the issue is not confirmed as actively exploited in CISA KEV. With a CVSS 4.0 base score of 2.1 and an independent CVSS 3.1 assessment of AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L, the risk is low and confined to availability with no demonstrated confidentiality or integrity impact.
Heap memory corruption in snappy-java 1.1.10.8 and earlier allows remote attackers to write attacker-influenced bytes past the bounds of the output array when an application decompresses untrusted compressed data through the typed Snappy.uncompress*Array APIs (such as uncompressIntArray, uncompressFloatArray, or uncompressDoubleArray), which size their result array using the uncompressed length divided by element size while forwarding the undivided length to the native JNI layer. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, C:N/I:L/A:L) no authentication or user interaction is needed, but exploitation is conditional: the consuming application must expose the typed decompression path to attacker-controlled input, and applications that only use the generic byte[] uncompress path are not exposed. Impact is currently rated Low integrity and Low availability (heap corruption and crash) with no confirmed confidentiality loss or demonstrated code execution, and no public exploit was identified at time of analysis; this is a genuine memory-corruption flaw but a moderate, not top-tier, priority, and no vendor-released fixed version is identified in the available data.
Imager::File::PNG versions from 1.003 before 1.004 for Perl write past the end of the row buffer reading a PNG with a tRNS transparency chunk in read_direct8. With a tRNS chunk, read_direct8() adds an alpha channel to the image it creates but still sizes the row buffer from the original channel count. libpng expands the transparency into that extra channel, so png_read_row() fills one channel more than the buffer holds, at one byte per sample, and writes width bytes past the end of the allocation. Palette images go to read_paletted() and 16-bit images to read_direct16(), which sizes its buffer from png_get_rowbytes() and allocates enough for the expanded row. The same reader ships bundled in the Imager distribution. Reading an attacker-supplied PNG through Imager->read() corrupts the heap, which can crash the process.
Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process.
Heap out-of-bounds read in the PoDoFo C++ PDF library (versions 1.0.0 through 1.1.0) lets a crafted PDF containing an Indexed color-space image cause the library to read past the end of its palette lookup buffer. An attacker must convince a victim to hand the malicious PDF to an application built on the affected library and have that application decode or render the embedded Indexed image; no authentication is required (CVSS 4.0 vector PR:N, AV:L, UI:P), and the practical impact is dominated by a process crash leading to denial of service, with only adjacent heap bytes potentially disclosed rather than targeted secret exfiltration. Exploitation yields a limited confidentiality gain and a high availability impact; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The flaw is fixed in PoDoFo 1.1.1.
An out-of-bounds read in OpenImageIO's BMP reader allows a crafted palette BMP to crash any process that decodes it, causing denial of service. Affected are versions prior to 3.0.16.0 and 3.1.11.0: a malformed file whose DIB header sets the palette flag but supplies an empty color table, combined with RLE4 or RLE8 compression, drives BmpInput::read_native_scanline into an invalid palette lookup. Exploitation requires the victim to process the attacker-supplied image (for example via oiiotool or an application linked against OpenImageIO), making the realistic risk concentrated in automated or batch image-ingestion pipelines; no public exploit identified at time of analysis, and CISA KEV does not list this issue.
Memory disclosure in Google Chrome prior to 153.0.8010.52 allows a local attacker to read out-of-bounds data through the browser's DataTransfer implementation, with the sandbox-crossing scope change (S:C) in the CVSS vector indicating the leaked memory can originate outside the renderer process rather than from within the attacker's own context. Per the assessed vector (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N, base 6.3) exploitation requires the attacker to already be running a local program on the victim's machine and to use social engineering to obtain user interaction, and it produces only confidentiality impact with no integrity or availability effect, so this is an information-disclosure bug rather than a sandbox escape or code-execution primitive. There is no public exploit code identified at time of analysis and the issue is not confirmed actively exploited (it is not in CISA KEV); Google has shipped version 153.0.8010.52, which resolves the flaw.
Denial of service in applications using the MongoDB C Driver's libbson library can be triggered by crafted BSON input with a zero document-length field, which causes an integer underflow (CWE-191) and a heap out-of-bounds read that crashes the process. The CVSS v4.0 vector indicates remote, unauthenticated exploitation (AV:N/PR:N/UI:N), but the vulnerability only affects code paths that pass untrusted BSON to bson_new_from_buffer(), and impact is limited to a process crash with no data disclosure or code execution. No public exploit code or active exploitation (CISA KEV) was identified in the provided intelligence.
Denial of service in rabbitmq-c (librabbitmq) versions prior to 0.16.0 lets an attacker-controlled or on-path AMQP server crash a connecting client during the login handshake by sending an undersized HEADER or METHOD frame. The malformed frame triggers an unsigned size_t underflow in the frame parser that defeats downstream bounds checks and causes an out-of-bounds read, terminating the client process. Per the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5) the impact is purely availability, requiring the victim to initiate a connection (UI:R); no public exploit identified at time of analysis, and TLS with proper certificate validation neutralizes the on-path variant.
Spoofed or injected ICMP echo replies can steer mport's mirror-latency selection toward an attacker-chosen mirror and, if the reply carries IP options, shift the parsed ICMP header past the hardcoded offset used by ping() in libmport/ping.c, causing an out-of-bounds read. The flaw affects MidnightBSD mport releases prior to 2.7.8 and is only reachable by an unauthenticated attacker on the same adjacent network segment who can place visible ICMP traffic on-path while an mport client is actively probing mirrors (assessed CVSS:3.1 AV:A/AC:H/PR:N/UI:N/C:N/I:L/A:L; CVSS 4.0 base 2.3). Impact is low and confined to the transient probing window; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released version 2.7.8 as the fix.
In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.
In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].
In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.
In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.
In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.
In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.
In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix out-of-bounds access in mmio copy helpers mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.
In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix max_qid race between configfs and controller allocation The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in sbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.
In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] <TASK> [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] </TASK> [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.
In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.
In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in <uapi/linux/atmdev.h> as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.
Out-of-bounds write in vgmstream (through r2117) lets an attacker corrupt heap memory when a crafted EA SCHl audio file is decoded, triggered inside vadpcm_read_coefs_be in src/coding/vadpcm_decoder.c via a manipulated coefficient entry/entries count. The vulnerable code path is reached from any application embedding the library - media players and game-audio converters that use vgmstream - but exploitation requires the victim to open or load the malicious file (passive user interaction); there is no network service to hit and no public exploit identified at time of analysis. The vendor rates it CVSS 4.0 5.3, while this assessment maps it to CVSS 3.1 AV:L/AC:L/PR:N/UI:R with Low confidentiality, integrity and availability impact and no demonstrated path to code execution.
Memory corruption in Qualcomm Snapdragon rear sensor IOCTL handling allows a local high-privileged attacker to execute code, tamper with data, or cause denial of service on affected devices. Exploitation requires local access and high privileges (PR:H) to invoke the rear (camera) sensor IOCTL, typically only reachable from a privileged camera HAL or system service; no user interaction is needed, but crafted parameters must be supplied to the vulnerable interface. No public exploit identified at time of analysis, and the required high privilege level narrows the practical attacker population.
Memory corruption in Qualcomm Snapdragon platforms allows an attacker who already holds a low-privileged local foothold on the device to corrupt memory by feeding oversized input into a copy routine that exceeds expected allocation limits, giving high impact to confidentiality, integrity, and availability of the affected component. The flaw is not remotely exploitable on its own: exploitation requires local access with low privileges (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) - for example a malicious or compromised application able to reach the vulnerable code path - and no user interaction is needed. No public exploit code has been identified at time of analysis, and no CISA KEV listing or EPSS score was provided; the referenced Qualcomm September 2026 security bulletin is the authoritative source for the specific affected chipsets and fixed versions.
Heap buffer overflow in an unspecified Ubuntu utility's duplicate_legacy_root_dir function can lead to high confidentiality, integrity, and availability impact when a local attacker convinces a user or automated job to process a crafted input, such as a malicious filesystem image or legacy-format file. The assessed CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates local access, no privileges required, and user interaction as the primary limiting factor, but the exact product, affected versions, and trigger condition are unconfirmed due to the record lacking product name, CWE, EPSS, KEV, and POC data. No public exploit identified at time of analysis.
Heap buffer overflow in the FAT-filesystem parsing code paths identified as _init_fats and fat_table_read - most likely the libparted FAT module used by GNU Parted and its fatresize component - allows memory corruption when a malformed FAT volume is parsed. The issue is local in scope (AV:L) and requires user interaction (UI:R): a victim must open a crafted disk/partition image or insert a removable device whose FAT table has been manipulated, and a parsing path (resize, inspection, or a mount helper such as udisks auto-mount handling) must actually read that volume. The assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H indicates unauthenticated local attackers can achieve high confidentiality, integrity, and availability impact if the bug is reliably triggered, though whether the overflow yields code execution rather than a crash is unproven and impact is amplified only if the parser runs with elevated privileges. No CISA KEV entry and no public exploit code have been identified - no public exploit identified at time of analysis - and no EPSS score was supplied; the exact affected package, version range, and default-configuration reachability remain unconfirmed from the available data.
An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.
Opening a specially crafted BIFS or LASeR scene file in GPAC 26.08-DEV can trigger a use-after-free in the scene-graph command handler, crashing the application. Only local exploitation is possible: the victim must load attacker-supplied media in a vulnerable pre-abi-16.24 build, there is no network-reachable trigger, and impact is limited to availability (denial of service) with no confidentiality or integrity effect. Publicly available exploit code exists (referenced PoC archive on GitHub), and the underlying flaw is remediated by the upstream fix released in abi-16.24 (commit e34f4ba); despite the public PoC this is a low-priority, low-real-risk issue given the local, user-interaction-dependent attack path.
Stack-based buffer overflow in the Dell Update Package (DUP) Framework, affecting all versions prior to 26.07.03, allows an unauthenticated attacker who can reach the affected component from an adjacent network segment (AV:A, PR:N, UI:N) to corrupt stack memory and potentially achieve code execution or crash the process. Dell scores this 6.5 with CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (availability-only), whereas independent assessment rates the impact as complete loss of confidentiality, integrity and availability (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), which aligns with the description's statement that the flaw can lead to remote execution; the practical constraint in both readings is the adjacency requirement rather than internet-wide reachability. No CISA KEV entry and no public exploit code were identified at time of analysis, and Dell has published DSA-2026-417 with a fixed release (26.07.03).
Heap-based buffer overflow in GPAC 26.07.0's Remotery-style WebSocket remote-monitoring handler (rmt_client_handle_ws_frame in src/utils/rmt_ws.c) lets remote attackers corrupt heap memory by sending a WebSocket frame whose advertised payload_size is manipulated, since the value is trusted when computing how much extra data to read. The CVSS 4.0 score is 6.9 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N and the E:P exploit-maturity flag; an independent assessment rates the memory-safety consequence more severely (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H), reflecting that availability impact can be complete once the interface is reached. Publicly available exploit code exists - a Python PoC (poc_rmt_ws_malicious_frame.py) is attached to the upstream GitHub issue - but there is no confirmation of active exploitation (no CISA KEV listing). The practical limiting factor is exposure: the rmt_ws handler must be compiled in, enabled, and network-reachable, which is not the default posture for typical GPAC/MP4Box usage.
Heap use-after-free in the HDF5 library (The HDF Group, all versions before 2.3.0) is triggered when an application such as h5dump reads a dataset whose compound datatype contains floating-point members, allowing a crafted .h5 file to crash the parsing process and, depending on heap layout and allocator behaviour, potentially corrupt memory further. Exploitation requires the victim to open a malicious file locally (local vector, mandatory user interaction, no authentication needed), so it is not remotely reachable on its own. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor's own CVSS 4.0 base of 4.6 aligns with the independent assessment that the reliably demonstrated impact is a crash rather than proven code execution.
An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.
In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.
An out-of-bounds read in the HTTP Cache-Control response header parser of the QtNetwork module lets a hostile or compromised HTTP server crash 64-bit client applications built on Qt 6.0.0-6.8.8 or 6.9.0-6.11.1 that use QNetworkAccessManager. The trigger is an excessively large Cache-Control header value returned to the requesting client; because the over-read is read-only, the outcome is limited to a denial of service (application crash) with no information disclosure and no code execution, and only the client side of the connection is affected - 32-bit builds are not affected. No public exploit code has been identified at time of analysis, and exploitation is not on-demand against an arbitrary target: the victim application must be induced to connect to an untrusted, attacker-controlled, or compromised server (reflected as AT:P in the CVSS 4.0 vector), which keeps real-world risk at a low-to-moderate level despite the presence of RCE and Information Disclosure tags in some feeds.
In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)
A heap-based buffer overflow in the Samsung Escargot JavaScript engine is reachable when a crafted bytecode-cache file is parsed, driven by an integer wraparound (CWE-190) in the string-table length handling inside CodeCacheReader::loadStringTable. Exploitation requires local write access to the engine's bytecode-cache directory (CVSS 5.5, AV:L/PR:L), and the impact is limited to availability - a crash or memory-corruption-induced denial of service with no confidentiality or integrity loss. No public exploit code or CISA KEV listing was identified at time of analysis, and the upstream fix (Samsung PR #1650) adds a bounds check rejecting any maxLength above STRING_MAXIMUM_LENGTH.
An out-of-bounds read in the ARP filter import handler (filter_arp_put_file.cgi) of Netcore NR255-V firmware 1.5.130703 lets an attacker who can reach the router's web management interface and supply a malformed, non-null-terminated string cause the string-handling API to read past the end of an allocated buffer, exposing adjacent process memory in the response. The flaw is rated CVSS 5.3 (CVSS:4.0/AV:N/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L), indicating a network-reachable, low-privilege issue with limited confidentiality and availability impact only — there is no confirmed integrity impact, no CISA KEV listing, and no confirmed public exploit code; the only public material is a VulnCheck advisory plus a third-party GitHub technical reference whose exploit content is unverified.
An integer overflow in Google Chrome's Compositing component (fixed in 153.0.8010.47) lets a remote attacker leak cross-origin data by getting a victim to open a crafted HTML page. Exploitation requires user interaction (the victim must load the page) but no authentication or elevated privileges, and the impact is limited to confidentiality - integrity and availability are unaffected per the CVSS vector. There is no public exploit code or CISA KEV listing at time of analysis, and the CVSS base score is only 4.3, so this is a browser-patching hygiene issue rather than an emergency incident response trigger.
Google Chrome for Android versions prior to 153.0.8010.47 contain an out-of-bounds read in the WebGL rendering path that allows a remote attacker to leak memory from outside the browser sandbox by luring a victim into opening a crafted HTML page. Google labels the Chromium security severity as Critical, while the published CVSS 3.1 base score is a comparatively modest 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) because the flaw yields a limited confidentiality leak rather than code execution or data modification. A vendor patch is available, and no public exploit code or CISA KEV entry was identified at the time of analysis.
A malicious or compromised IMAP server can trigger an out-of-bounds read in the IMAP response parser by sending an untagged '* ID' response, crashing Thunderbird. The affected parsing path is reachable before authentication. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
A maliciously constructed IMAP line could cause an out-of-bounds buffer read. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
Authenticated attackers holding Admin privileges on HPE Networking EdgeConnect SD-WAN Gateways can send a crafted request to an API endpoint and trigger a classic buffer overflow (CWE-120), potentially achieving arbitrary command execution on the appliance's underlying operating system. ENISA EUVD lists affected builds across the 9.4.x, 9.5.x, 9.6.x and 9.7.x release branches, with the HPE advisory as the sole authoritative reference. No public exploit code and no CISA KEV entry were reported at time of analysis, and the vendor's 5.5 CVSS score omits any confidentiality impact despite the description claiming full OS-level command execution.
A buffer overflow in the web-based management interface of HPE Networking EdgeConnect SD-WAN Gateways allows an authenticated administrator to crash or destabilize the appliance, producing a denial-of-service condition. All maintenance branches 9.4.0.0 through 9.4.8.2, 9.5.0.0 through 9.5.8.1, 9.6.0.0 through 9.6.3.1, and 9.7.0.0 are affected per ENISA EUVD tracking. The CVSS base of 5.5 with PR:H reflects that high administrative privileges are required, so this is not an unauthenticated remote outage; no public exploit code or CISA KEV listing was identified at time of analysis.
A buffer overflow in a system service of the underlying operating system on HPE Networking EdgeConnect SD-WAN Gateways allows an unauthenticated attacker who already sits on an adjacent network segment to crash the affected service, temporarily disrupting SD-WAN and branch network operations. All editions of the 9.4.x (up to 9.4.8.2), 9.5.x (up to 9.5.8.1), 9.6.x (up to 9.6.3.1) and 9.7.0.0 releases are listed as affected by the vendor. The impact is degraded availability rather than confidentiality or code execution, exploitation requires high attack complexity, and no public exploit code or CISA KEV entry was identified at time of analysis.
A buffer overflow in the underlying operating system of HPE Networking EdgeConnect SD-WAN Gateways lets an unauthenticated remote attacker send specially crafted packets to an affected service and corrupt its memory. Rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L, CWE-120), successful exploitation degrades the integrity and availability of the gateway service without exposing confidential data. No CISA KEV listing and no public exploit code were identified in the supplied intelligence, and no EPSS score was provided, so exploitation is currently assessed as opportunistic rather than confirmed in the wild.
An out-of-bounds write in the Android kernel GNSS link driver lets a local process that already holds System execution privileges corrupt kernel memory and escalate to kernel-level code execution. The defect (CWE-787) is a missing bounds check in link_load_gnss_image() in link_device.c, requires no user interaction, and is addressed through Google's September 2026 Android/Pixel security bulletin. No public exploit code or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds read in the Pixel-specific physmem_extmem driver (physmem_extmem_linux.c) of the Android kernel lets a local process with low privileges read kernel memory that was never initialized, exposing potentially sensitive data. No user interaction or elevated execution privileges are required, and the impact is limited to confidentiality (CVSS 5.5, AV:L/PR:L/C:H). The issue is addressed in the September 2026 Android/Pixel security bulletin; no public exploit code or CISA KEV listing was identified at the time of analysis.
An out-of-bounds write in the Android kernel, caused by a missing bounds check, allows an attacker who already holds System-level execution privileges on a device to corrupt kernel memory and escalate to full kernel/root privileges. The flaw is reachable only with local access (AV:L, PR:H) and requires no user interaction, and the associated CVSS score of 6.7 reflects high integrity, confidentiality and availability impact rather than ease of reach. No public exploit code or CISA KEV active-exploitation listing was provided in the available intelligence, so this is currently assessed as a patch-priority local privilege-escalation bug rather than a known exploited threat.
A missing bounds check in multiple locations of Android kernel code allows a local attacker who already holds System execution privileges to trigger an out-of-bounds write and escalate to higher, kernel-level privileges on affected devices. Google Android builds that ship the impacted kernel code are affected, with fixes published through the September 2026 Pixel/Android security bulletin. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 6.7 score reflects the demanding high-privilege prerequisite rather than any remote reachability.
Out-of-bounds write in the Android kernel lets a local attacker who already holds System-level execution privileges corrupt memory and escalate to full kernel/root code execution without any user interaction. Devices running Android builds that have not yet adopted the September 2026 (2026-09-01) security patch level are affected, with Google rating the flaw High at CVSS 6.7. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS score was supplied with this data.
An out-of-bounds read in the Android kernel driver routine gf_algo_get_cached_dump_data (gf_algo.c) lets a locally positioned attacker with limited privileges read past the end of a buffer and leak kernel memory contents, with no user interaction required. Pixel builds that ship the vulnerable gf_ driver are affected, and the September 2026 Android/Pixel security bulletin provides the fix. Neither public exploit code nor a CISA KEV entry was present in the supplied intelligence, and no EPSS score was provided, so active exploitation is unconfirmed and the practical threat at time of analysis is a local, post-compromise or malicious-app information leak.
Memory corruption in the Android Trusted Execution Environment (TEE) allows a local attacker who already holds System execution privileges to escalate privileges within the secure world by supplying improperly validated input to an affected secure-world interface. The flaw is local-only (AV:L), requires high pre-existing privileges (PR:H), and needs no user interaction (UI:N), yielding high confidentiality, integrity, and availability impact if the corrupted trusted application is reached; Google rates it 6.7 (Medium). Risk is tempered by the significant foothold required, the local-only attack surface, and the low EPSS score (0.11%, 2nd percentile); no public exploit code has been identified and the flaw is not listed in CISA KEV, with fixes delivered in the Pixel security bulletin dated 2026-09-01.
Let me synthesize. CVE-2026-56923: Android kernel TIPC virtio driver (tipc_virtio_dev.c) handle_unmap_req race condition memory corruption, local EoP. CVSS 3.1: AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H → 6.4. Note PR:H which is odd for a local privilege escalation "with no additional execution privileges needed" — the description says no additional execution privileges needed. Hmm, the CVSS says PR:H. There's a conflict: description says local EoP with no additional execution privileges needed (implying PR:N or PR:L?), while CVSS vector says PR:H. This is a data conflict worth noting in confidence_notes and risk_assessment. Actually Android's kernel CVEs for local EoP typically are AV:L/AC:H/PR:H/UI:N in their bulletins... Actually Android uses PR:H sometimes? Hmm. Let me note the conflict: description claims "no additional execution privileges needed" but vector shows PR:H (high privileges required), which typically means the attacker already needs elevated privileges — contradictory for an EoP. State explicitly. Product name: "Android Kernel" — 2 words. Or "TIPC Virtio Driver". Primary product per CPE: google:android. I'd say "Android Kernel". Tags: Privilege Escalation, Buffer Overflow, Google, Race Condition. Buffer Overflow mislabeled? The CWE is race condition/memory corruption. Hmm — "Buffer Overflow" tag is arguably a mislabeled tag since CWE-362 race condition and description says memory corruption not buffer overflow. But memory corruption could involve buffer overflow. I'd be moderately confident... The instructions say only emit flag when clearly wrong and verifiable. Memory corruption due to race condition — buffer overflow is a specific subclass. It's arguably mislabeling. I could flag it with low/medium confidence. Hmm. I think I'll flag it as mislabeled_tag with medium confidence since the CVE is a race condition leading to memory corruption, no buffer overflow specified. Actually careful — race conditions can cause buffer overflows (TOCTOU). Risky.