{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2025-39928", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-04-16T07:20:57.147Z", "datePublished": "2025-10-01T08:07:15.530Z", "dateUpdated": "2026-08-05T12:06:07.320Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T12:06:07.320Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: rtl9300: ensure data length is within supported range\n\nAdd an explicit check for the xfer length to 'rtl9300_i2c_config_xfer'\nto ensure the data length isn't within the supported range. In\nparticular a data length of 0 is not supported by the hardware and\ncauses unintended or destructive behaviour.\n\nThis limitation becomes obvious when looking at the register\ndocumentation [1]. 4 bits are reserved for DATA_WIDTH and the value\nof these 4 bits is used as N + 1, allowing a data length range of\n1 <= len <= 16.\n\nAffected by this is the SMBus Quick Operation which works with a data\nlength of 0. Passing 0 as the length causes an underflow of the value\ndue to:\n\n(len - 1) & 0xf\n\nand effectively specifying a transfer length of 16 via the registers.\nThis causes a 16-byte write operation instead of a Quick Write. For\nexample, on SFP modules without write-protected EEPROM this soft-bricks\nthem by overwriting some initial bytes.\n\nFor completeness, also add a quirk for the zero length.\n\n[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2" } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H", "baseScore": 7.1, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - The vulnerable code is reached only through the `I2C_SMBUS` ioctl on the local `/dev/i2c-N` character device (or an in-kernel SMBus caller); there is no network- or link-layer path to `rtl9300_i2c_smbus_xfer()`. No physical access is required, only local access to the device node.\nAC:L - Triggering is fully deterministic and attacker-controlled — a single `I2C_SMBUS` ioctl with `size = I2C_SMBUS_QUICK` (or a Send Byte write) always drives `(len - 1) & 0xf` to 0xf and emits the 16-byte transfer. No race, no memory-layout dependency, and it succeeds on the first attempt.\nPR:L - `i2cdev_open()` performs no capability check whatsoever; reachability depends solely on DAC permissions on `/dev/i2c-N`, and the standard i2c-tools udev rule grants the unprivileged `i2c` group 0660 access precisely so ordinary users can run `i2cdetect`/`i2cget`. An unprivileged local account in that group therefore reaches the flaw without root.\nUI:N - The attacker issues the ioctl directly from its own process; no victim action, mount, or file open is needed. (An administrator running `i2cdetect` merely provides an additional accidental trigger.)\nS:U - The destructive writes go to I2C/SMBus peripherals that are administered by the same kernel security authority that owns the bus and the device node, so the impact stays within the vulnerable component's scope. No hypervisor, IOMMU, or sandbox boundary is crossed.\nC:N - No kernel memory is read out of bounds and nothing is copied back to the attacker — the erroneous transfer is write-directed onto the I2C bus. Any bus data an attacker could observe is already reachable through the same fd, so no confidentiality boundary is crossed.\nI:H - A nominally read-only/no-op operation instead performs an unauthorized 16-byte write of stale controller-register contents into the addressed device's persistent storage, overwriting SFP/DAC EEPROM identification bytes and potentially board EEPROM, PoE controller, or sensor configuration. This is arbitrary, attacker-directed corruption of non-volatile hardware state.\nA:H - Overwriting an SFP/DAC module's EEPROM soft-bricks it — the module no longer identifies and the switch port is permanently down until the hardware is reflashed or physically replaced, and every module on the bus can be destroyed in one sweep. On a managed switch this is a complete, non-self-healing loss of availability of the affected ports or the appliance." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/i2c/busses/i2c-rtl9300.c" ], "versions": [ { "version": "c366be720235301fdadf67e6f1ea6ff32669c074", "lessThan": "c91382328fc89f73144d5582f2d8f1dd3e41c8f7", "status": "affected", "versionType": "git" }, { "version": "c366be720235301fdadf67e6f1ea6ff32669c074", "lessThan": "06418cb5a1a542a003fdb4ad8e76ea542d57cfba", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/i2c/busses/i2c-rtl9300.c" ], "versions": [ { "version": "6.13", "status": "affected" }, { "version": "0", "lessThan": "6.13", "status": "unaffected", "versionType": "semver" }, { "version": "6.16.8", "lessThanOrEqual": "6.16.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.17", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.13", "versionEndExcluding": "6.16.8" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.13", "versionEndExcluding": "6.17" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/c91382328fc89f73144d5582f2d8f1dd3e41c8f7" }, { "url": "https://git.kernel.org/stable/c/06418cb5a1a542a003fdb4ad8e76ea542d57cfba" } ], "title": "i2c: rtl9300: ensure data length is within supported range", "x_generator": { "engine": "bippy-1.2.0" } }, "adp": [ { "metrics": [ { "cvssV3_1": { "scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE" } }, { "other": { "type": "ssvc", "content": { "id": "CVE-2025-39928", "role": "CISA Coordinator", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "version": "2.0.3", "timestamp": "2026-01-14T17:39:24.283668Z" } } } ], "problemTypes": [ { "descriptions": [ { "lang": "en", "type": "CWE", "cweId": "CWE-191", "description": "CWE-191 Integer Underflow (Wrap or Wraparound)" } ] } ], "title": "CISA ADP Vulnrichment", "providerMetadata": { "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-01-14T17:42:45.737Z" } } ] } }