PULSE
FEED
ransomn0n reclama a Company #111 · AEransomeverest reclama a OR Technology · Technologyransomeverest reclama a Burris & MacOmber · Professional Servicesransomeverest reclama a Energy Storage Terminal in Singapore · SG · Energy & Utilitiesransomeverest reclama a Point Robotics · Technologyransomeverest reclama a Natuzzi · IT · Manufacturingransomeverest reclama a TECNA ICE · IT · Manufacturingransomeverest reclama a MediSolution · Healthcareransomeverest reclama a SleepEx LabRetriever · Healthcareransomcrypto24 reclama a Antah HealthCare Group · MY · Healthcareransomcrypto24 reclama a DATEM, Inc. · PH · Technologyransomwhitearmor reclama a gamblinglore · Retail & E-Commerceransomwhitearmor reclama a Verification · Technologyransomulose reclama a zzq-testransomn0n reclama a Company #111 · AEransomeverest reclama a OR Technology · Technologyransomeverest reclama a Burris & MacOmber · Professional Servicesransomeverest reclama a Energy Storage Terminal in Singapore · SG · Energy & Utilitiesransomeverest reclama a Point Robotics · Technologyransomeverest reclama a Natuzzi · IT · Manufacturingransomeverest reclama a TECNA ICE · IT · Manufacturingransomeverest reclama a MediSolution · Healthcareransomeverest reclama a SleepEx LabRetriever · Healthcareransomcrypto24 reclama a Antah HealthCare Group · MY · Healthcareransomcrypto24 reclama a DATEM, Inc. · PH · Technologyransomwhitearmor reclama a gamblinglore · Retail & E-Commerceransomwhitearmor reclama a Verification · Technologyransomulose reclama a zzq-test
← Todos los CVEs
CVE Watch19 oct 2026

CVE-2025-39928

In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an expl

CVSS

7.1

Alto

EPSS

0.1%

p3

KEV

—

Exploit Today

1

0-100

Publicado: 1 oct 2025 · Última mod.: 19 oct 2026 · CWE-191

EPSS · 30d
0.1%EPSS · 30 días0.1%
2026-09-282026-10-26
Descripción técnica

In the Linux kernel, the following vulnerability has been resolved: i2c: rtl9300: ensure data length is within supported range Add an explicit check for the xfer length to 'rtl9300_i2c_config_xfer' to ensure the data length isn't within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour. This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 <= len <= 16. Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to: (len - 1) & 0xf and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes. For completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2

Referencias oficiales
CVEs relacionados
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-829477.1 ALT
6.4%
——2SOEM version 2.0.0 and earlier contains multiple vulnerabilities in frame processing where a malicious device can cause the master to read data outside allocated buffers. The software uses length and offset values from device messages without validating them against buffer sizes. This can cause the master to access invalid memory locations, potentially disclosing sensitive information or causing crashes.23h
CVE-2026-703888.3 ALT
11.5%
——3SOEM version 2.0.0 and earlier contains vulnerabilities where a malicious device on the network can send specially crafted messages that cause the master to write data outside allocated memory boundaries. The software performs arithmetic on message length values without proper validation, allowing negative or extremely large values to bypass safety checks. This can corrupt memory and potentially allow an attacker to execute arbitrary code on the master system.23h
CVE-2026-1118088.6 ALT
35.2%
——11Apache Traffic Server can be used to exhaust an HTTP/1.1 origin's worker pool via a malformed padded HTTP/2 DATA frame. This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.4d
CVE-2026-74755—
10.0%
——3An integer underflow in the mcpack2pb component of Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to crash a bRPC server by sending a request containing a string field with a zero value_size. The UnparsedValue::as_string() function computes `_size - 1` without validating `_size`; when value_size is 0 the expression underflows to SIZE_MAX, resize() throws std::length_error, and because the exception is not caught on the request parsing path the process aborts (SIGABRT). Root Cause: In src/mcpack2pb/parser.cpp, UnparsedValue::as_string() resizes the output string to `_size - 1`, where `_size` is the value_size of a string field taken directly from the network data. A value_size of 0 underflows the unsigned size_t, and the subsequent resize() throws an exception that is not caught. Affected Scenarios: bRPC servers that accept nshead frames wired to the ubrpc mcpack2 adaptor (for example the NsheadService + UbrpcMcpack2Adaptor deployment pattern) can be crashed by a single unauthenticated request. Stock open-source bRPC registers the ubrpc/nshead_mcpack protocols as client-only, so default server configurations are not affected. How to Fix: 1. Upgrade bRPC to a version that includes this fix. 2. Apply the patch in PR  https://github.com/apache/brpc/pull/345016h
CVE-2026-563867.5 ALT
54.0%
——16Integer underflow and out-of-bounds read in the HTTP/2 server DATA frame parser in Apache bRPC allows an unauthenticated remote attacker to cause denial of service by sending a malformed DATA frame with the PADDED flag set and a zero-length payload. Root Cause: The HTTP/2 DATA frame handler computed the fragment size from the attacker-controlled payload length and, when the PADDED flag was present, decremented the fragment size before ensuring that the frame contained the mandatory pad length byte. A zero-length padded DATA frame could therefore underflow the unsigned fragment size and read the pad length byte past the end of the frame buffer. Affected Scenarios: Apache bRPC servers that accept HTTP/2 traffic are affected when a remote client can send crafted HTTP/2 frames to the server. HTTP/2 may be reached through cleartext h2c detection on an HTTP port or through TLS ALPN negotiation. How to Fix: (Choose one of the following options) 1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3325 Note: The fix validates that a padded DATA frame has enough payload bytes for the pad length field before decrementing the fragment size or reading the pad length byte. Malformed zero-length padded DATA frames are rejected with HTTP/2 FRAME_SIZE_ERROR.16h
CVE-2026-111075—
30.9%
——9In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset` fields during `DataDescriptor` message deserialization. An unauthenticated remote attacker can send a crafted network payload that triggers an unsigned integer underflow in `DataDescriptor::getPayloadSize()` and `DataDescriptor::getNextDescriptor()`. This results in an out-of-bounds heap read and an immediate process crash (SIGSEGV), causing a denial of service.19h