Answer in brief
CVE-2025-40269 records a Unknown severity vulnerability in ALSA: usb-audio: Fix potential overflow of PCM transfer buffer. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2025-40269 records a Unknown severity vulnerability in ALSA: usb-audio: Fix potential overflow of PCM transfer buffer. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=02c56650f3c118d3752122996d96173d26bb13aa <480a1490c595a242f27493a4544b3efb21b29f6a || >=5ef30e443e6d3654cccecec99cf481a69a0a6d3b <ab0b5e92fc36ee82c1bd01fe896d0f775ed5de41 || >=99703c921864a318e3e8aae74fde071b1ff35bea <282aba56713bbc58155716b55ca7222b2d9cf3c8 || >=2d50acd7dbd0682a56968ad9551341d7fc5b6eaf <c4dc012b027c9eb101583011089dea14d744e314 || >=aba41867dd66939d336fdf604e4d73b805d8039f <e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360 || >=d288dc74f8cf95cb7ae0aaf245b7128627a49bf3 <d67dde02049e632ba58d3c44a164a74b6a737154 || >=f0bd62b64016508938df9babe47f65c2c727d25c <6a5da3fa80affc948923f20a4e086177f505e86e || >=f0bd62b64016508938df9babe47f65c2c727d25c <217d47255a2ec8b246f2725f5db9ac3f1d4109d7 || >=f0bd62b64016508938df9babe47f65c2c727d25c <ef592bf2232a2daa9fffa8881881fc9957ea56e9 || >=f0bd62b64016508938df9babe47f65c2c727d25c <ece3b981bb6620e47fac826a2156c090b1a936a0 || >=f0bd62b64016508938df9babe47f65c2c727d25c <98e9d5e33bda8db875cc1a4fe99c192658e45ab6 || >=f0bd62b64016508938df9babe47f65c2c727d25c <d2c04f20ccc6c0d219e6d3038bab45bc66a178ad || >=f0bd62b64016508938df9babe47f65c2c727d25c <05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf || >=4.4.229 <4.4.230 || >=4.9.229 <4.9.230 || >=4.14.186 <4.14.188 || >=4.19.130 <4.19.132 || >=5.4.49 <5.4.51 || >=5.7.6 <5.7.8 | 480a1490c595a242f27493a4544b3efb21b29f6a, ab0b5e92fc36ee82c1bd01fe896d0f775ed5de41, 282aba56713bbc58155716b55ca7222b2d9cf3c8, c4dc012b027c9eb101583011089dea14d744e314, e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360, d67dde02049e632ba58d3c44a164a74b6a737154, 6a5da3fa80affc948923f20a4e086177f505e86e, 217d47255a2ec8b246f2725f5db9ac3f1d4109d7, ef592bf2232a2daa9fffa8881881fc9957ea56e9, ece3b981bb6620e47fac826a2156c090b1a936a0, 98e9d5e33bda8db875cc1a4fe99c192658e45ab6, d2c04f20ccc6c0d219e6d3038bab45bc66a178ad, 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf, 4.4.230, 4.9.230, 4.14.188, 4.19.132, 5.4.51, 5.7.8 |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Dec 6, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=02c56650f3c118d3752122996d96173d26bb13aa <480a1490c595a242f27493a4544b3efb21b29f6a || >=5ef30e443e6d3654cccecec99cf481a69a0a6d3b <ab0b5e92fc36ee82c1bd01fe896d0f775ed5de41 || >=99703c921864a318e3e8aae74fde071b1ff35bea <282aba56713bbc58155716b55ca7222b2d9cf3c8 || >=2d50acd7dbd0682a56968ad9551341d7fc5b6eaf <c4dc012b027c9eb101583011089dea14d744e314 || >=aba41867dd66939d336fdf604e4d73b805d8039f <e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360 || >=d288dc74f8cf95cb7ae0aaf245b7128627a49bf3 <d67dde02049e632ba58d3c44a164a74b6a737154 || >=f0bd62b64016508938df9babe47f65c2c727d25c <6a5da3fa80affc948923f20a4e086177f505e86e || >=f0bd62b64016508938df9babe47f65c2c727d25c <217d47255a2ec8b246f2725f5db9ac3f1d4109d7 || >=f0bd62b64016508938df9babe47f65c2c727d25c <ef592bf2232a2daa9fffa8881881fc9957ea56e9 || >=f0bd62b64016508938df9babe47f65c2c727d25c <ece3b981bb6620e47fac826a2156c090b1a936a0 || >=f0bd62b64016508938df9babe47f65c2c727d25c <98e9d5e33bda8db875cc1a4fe99c192658e45ab6 || >=f0bd62b64016508938df9babe47f65c2c727d25c <d2c04f20ccc6c0d219e6d3038bab45bc66a178ad || >=f0bd62b64016508938df9babe47f65c2c727d25c <05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf || >=4.4.229 <4.4.230 || >=4.9.229 <4.9.230 || >=4.14.186 <4.14.188 || >=4.19.130 <4.19.132 || >=5.4.49 <5.4.51 || >=5.7.6 <5.7.8 | 480a1490c595a242f27493a4544b3efb21b29f6a, ab0b5e92fc36ee82c1bd01fe896d0f775ed5de41, 282aba56713bbc58155716b55ca7222b2d9cf3c8, c4dc012b027c9eb101583011089dea14d744e314, e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360, d67dde02049e632ba58d3c44a164a74b6a737154, 6a5da3fa80affc948923f20a4e086177f505e86e, 217d47255a2ec8b246f2725f5db9ac3f1d4109d7, ef592bf2232a2daa9fffa8881881fc9957ea56e9, ece3b981bb6620e47fac826a2156c090b1a936a0, 98e9d5e33bda8db875cc1a4fe99c192658e45ab6, d2c04f20ccc6c0d219e6d3038bab45bc66a178ad, 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf, 4.4.230, 4.9.230, 4.14.188, 4.19.132, 5.4.51, 5.7.8 |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Dec 6, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].
Quoted source text, attributed separately from HOL analysis.