media: firedtv: possible out of bounds write from a CAM response length
Maoyi Xie <[email protected]> Thu, 18 Jun 2026 19:58:12 +0800
| Newsgroups | gmane.linux.drivers.video-input-infrastructure,gmane.linux.kernel.firewire.devel,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi all, I think avc_ca_app_info() in drivers/media/firewire/firedtv-avc.c can write past the 256 byte CA message buffer when the CI-CAM returns a large length. I would appreciate it if you could take a look. The copy takes its length straight from the CAM response. pos = get_ca_object_pos(r); ... memcpy(&app_info[5], &r->operand[pos], 5 + r->operand[pos + 4]); r->operand[] holds the raw AV/C response bytes the CAM sent, and both pos and the length operand[pos + 4] come from those bytes. The destination app_info is reply->msg, the 256 byte msg[] field of struct ca_msg. With a length byte of 0xff the copy writes 5 + 255 bytes starting at app_info[5], which runs about 9 bytes past the 256 byte buffer. There is a FIXME right above the copy that asks for exactly this validation. The same unbounded pattern is in avc_ca_get_mmi() a few lines down. This looks like the unfixed sibling of CVE-2021-42739. That fix added bounds only to avc_ca_pmt(), the host to CAM PMT path. It left the CAM to host app_info and mmi response paths untouched, and those are the more natural attacker direction. The path is reachable from userspace. A CA_SEND_MSG with an APP_INFO_ENQUIRY tag followed by a CA_GET_MSG lands in avc_ca_app_info(), which then copies the CAM response. The attacker is a malicious or faulty FireDTV CI-CAM, or a spoofed FireWire node that answers the request. I reproduced it under KASAN on 7.1-rc7. A length of 0xff makes KASAN report a slab out of bounds write past the CA message buffer. A small length stays clean. The fix I tried bounds pos and the device length in both avc_ca_app_info() and avc_ca_get_mmi() so the copy stays in range. Does this look like a real bug to you? The code predates the git history, so I am not sure what to put in a Fixes tag. I could reference 35d2969ea3c7, the commit that bounded avc_ca_pmt() for CVE-2021-42739, since this is the same class left unfixed. I am happy to send a proper patch. Thanks, Maoyi https://maoyixie.com/