| Título | libimobiledevice fa0f79190142bc309307967c058f89c1b36eb6b8 - version 1.4.0 heap pointer leak |
|---|
| Descrição | 8-byte memcpy from a short buffer (handle leak)
Location: src/afc.c:868-872 (afc_file_open) and src/afc.c:1099-1103 (afc_file_tell)
if ((ret == AFC_E_SUCCESS) && (bytes > 0) && data) {
memcpy(handle, data, sizeof(uint64_t)); // only checks bytes > 0
Root cause. bytes (peer-controlled current_count) is checked > 0, not >= sizeof(uint64_t). A 1–7-byte response makes memcpy read 8 bytes from a buffer that only received bytes bytes.
On glibc 64-bit, malloc(1) has a 24-byte usable area, so the 8-byte read stays inside the chunk and copies stale heap contents past the received data — typically low bytes of a stale tcache next from when the chunk sat on the freelist. Not the live header and not main_arena. Under ASAN or other allocators this is a true OOB read. The leak is observable because the poisoned handle is echoed back by afc_file_read (readinfo->handle, src/afc.c:906). Note handle == 0 is rejected (src/afc.c:896), so the peer must return at least 1 non-zero byte.
Trigger (peer): reply to FILE_OPEN with FILE_OPEN_RES of 1–7 bytes; victim runs afc_file_open → afc_file_read → afc_file_close. Peer prints RECV handle=0x… and OOB_bytes_in_handle=….
Impact. Heap info leak (stale chunk / prior-freelist bytes) reflected back to the peer — useful for defeating ASLR in a follow-up Bug #2 exploit; not a crash by itself.
|
|---|
| Fonte | ⚠️ https://bohmid-com.vercel.app/#/article/blog-afc-writeup |
|---|
| Utilizador | ahmed0000 (UID 51651) |
|---|
| Submissão | 01/10/2026 17h25 (há 24 dias) |
|---|
| Moderação | 25/10/2026 18h44 (24 days later) |
|---|
| Estado | Aceite |
|---|
| Entrada VulDB | 426300 [libimobiledevice até 1.4.0 AFC File src/afc.c afc_file_open bytes Divulgação de Informação] |
|---|
| Pontos | 20 |
|---|