CVE-2026-68348

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The malformed blob is consumed by request_firmware() from the local firmware search path during tas2781 codec probe (tasdevice_dsp_parser/tas2781_load_calibration); there is no network, adjacent-network, or peer-supplied data path into the parser, so local presence on the affected system is required.

AC:LAttack complexity, low

Simply omitting the NUL terminator at the end of a coef/cal .bin file makes strlen() run past fmw->size deterministically on every load — no race, no timing window, and no memory-layout precondition the attacker cannot influence.

PR:LPrivileges required, low

The parsing path contains no capability, credential, or privilege check whatsoever, and the firmware search path on many embedded/Android/appliance deployments lives on a vendor or data partition writable by non-root system accounts; a low-privileged local account is therefore sufficient to be positioned to place the blob.

UI:NUser interaction, none

Parsing runs from the asynchronous request_firmware_nowait() completion callback during device probe/bind; once the file is in place it is consumed automatically at the next boot or driver bind with no victim action required.

S:UScope, unchanged

The out-of-bounds read occurs in kernel memory belonging to the same kernel that hosts the vulnerable codec driver, with no crossing of a VM, IOMMU, or sandbox boundary.

C:HConfidentiality impact, high

strlen() is unbounded — it walks from the description offset through arbitrary kernel memory adjacent to the firmware buffer until a zero byte is found, so the read is not confined to a few bytes and touches heap/vmalloc contents outside the intended allocation.

I:NIntegrity impact, none

The defect is purely a read: the computed length is re-validated against fmw->size afterwards (and int/size_t promotion makes overflowed sums fail the check), so no out-of-bounds write or corrupted parse offset results from the OOB strlen.

A:HAvailability impact, high

Firmware buffers are vmalloc/kmalloc allocations, so a strlen() walk past the end readily crosses into an unmapped page or guard page and produces a kernel oops/panic, which is High availability impact.