CVE-2024-52319
In the Linux kernel, the following vulnerability has been resolved: mm: use aligned address in clear_gigantic_page() In current kernel, hu
CVSS
7.8
Alto
EPSS
0.2%
p12
KEV
—
Exploit Today
4
0-100
Publicado: 11 ene 2025 · Última mod.: 4 ago 2026 · CWE-787
0.2%EPSS · 30 días0.2%
2026-07-202026-08-16
In the Linux kernel, the following vulnerability has been resolved: mm: use aligned address in clear_gigantic_page() In current kernel, hugetlb_no_page() calls folio_zero_user() with the fault address. Where the fault address may be not aligned with the huge page size. Then, folio_zero_user() may call clear_gigantic_page() with the address, while clear_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for clear_gigantic_page().
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-731949.1 CRÍ10.4%
——3DBI versions before 1.652 for Perl allow a heap out-of-bounds write via an unvalidated numeric placeholder that sets the binder counter in preparse.
preparse reserves seven output bytes per input byte, the width of the longest ':p99999' expansion. The ':N' branch parses the number with `atoi(src)` and assigns it to the binder counter with no range check, so a statement containing ':2147483648' leaves the counter negative (-2147483648 with glibc, where atoi wraps). Each following '?' then expands through `sprintf(start, ":p%d", idx++)` to ':p-2147483648', 14 bytes with the terminating NUL where the buffer budgets 7. The placeholder limit added in 1.650 tests the counter against 99,999, which a negative counter passes.
Any caller that preparses an untrusted statement into ':pN' style placeholders gets a heap out-of-bounds write that grows with the number of '?' marks following the poisoned placeholder. The '?' and '%s' return styles compare the parsed number against the expected sequence and error out, and are unaffected.11hCVE-2026-731939.8 CRÍ10.1%
——3DBI versions before 1.652 for Perl allow a heap out-of-bounds write on 32-bit perl via an integer wraparound in the output buffer size computed by preparse.
preparse reserves its output buffer with `newSV(strlen(statement) * 7 + 16)`, budgeting seven output bytes per input byte for the longest ':p99999' expansion. The product is computed in STRLEN, which is 32 bits wide on a 32-bit perl build, so a statement of 613,566,757 bytes multiplies to 4,294,967,299, wraps modulo 2^32 to 3, and reserves 19 bytes. The parser then copies the statement out through a raw pointer with no capacity check, writing the whole 585 MB input past the end of the allocation. The 99,999 placeholder limit does not bound this path, which is reached by ordinary non-placeholder content.
Any caller that passes an untrusted statement of that length to preparse on a 32-bit perl gets a heap out-of-bounds write of attacker controlled bytes. Builds with a 64-bit STRLEN are not affected, since the wrap there needs a statement of about 2.3 exabytes.11hCVE-2026-123634.2 MED6.5%
——2The LoRaWAN Fragmented Data Block Transport service (subsys/lorawan/services/frag_transport.c) does not validate the fragment counter in a received DATA_FRAGMENT command before forwarding it to the configured decoder. In frag_transport_package_callback() the value frag_counter = hdr->frag_index_n & 0x3FFF is taken directly from the downlink payload and passed to the decoder, which derives an array index and flash offset as frag_counter - 1. DataFragment fragments are 1-indexed, so a frag_counter of 0 underflows that arithmetic.
With the default Semtech/LoRaMAC-node decoder, this reaches FragDecoder.FragNbMissingIndex[fragCounter - 1] = 0; in FragDecoderProcess(), where fragCounter - 1 evaluates to -1 and writes a uint16_t zero out of bounds, just before the array and into the adjacent MatrixM2B recovery-matrix state of the static decoder object (CWE-787). A companion write derives a wild flash offset, but that path is rejected by the flash_area_write() bounds check. The in-tree low-memory decoder (frag_dec()) is not corrupted: its out-of-range bit-array and flash accesses are caught by sys_bitarray_ and flash_area_ bounds checks.
The handler is the registered downlink callback for the fragmentation transport port, reachable whenever an active fragmentation session exists, so the triggering byte is attacker-influenceable LoRaWAN/FUOTA network input. Triggering it requires authenticated downlinks (LoRaWAN MAC session keys or a malicious/compromised network or FUOTA server) and an active fragmentation session. The impact is contained: corruption of decoder state and denial of the firmware-update (FUOTA) session rather than controllable memory corruption or code execution. The fix adds a transport-layer check that rejects frag_counter == 0, closing the defect for both decoder backends.3dCVE-2026-13196—0.9%
——0Nozomi Networks Labs identified a CWE-787: Out-of-bounds Write vulnerability in the process-image management functionality of KUNBUS piControl in version 2.6.2 that allows a local authenticated attacker with device configuration access to write attacker-controlled data outside the bounds of the process-image buffer and corrupt adjacent kernel memory, resulting in kernel memory corruption and denial of service, by supplying crafted device configuration data and crafted input through the piControl character device.3dCVE-2026-185117.3 ALT12.5%
——4IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local authenticated attacker to generate a stack-based buffer overflow in the Native IBM i JSSE provider, caused by improper bounds checking during TLS session establishment. A local attacker could overflow a fixed-length buffer and execute arbitrary code on the system or cause the JVM process to crash.19hCVE-2026-180864.5 MED0.4%
——0IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local attacker to execute arbitrary code or cause a denial of service due to improper bounds checking.4d