A use-after-free cache-key confusion was found in dnsmasq's TFTP prefetch path in get_block() (src/tftp.c). The prefetch cache uses daemon->srv_save (a void* pointer to the tftp_transfer struct) and a static saved_offset as cache keys. When a transfer completes, free_transfer() frees the transfer struct without clearing daemon->srv_save, leaving a dangling pointer as a valid cache key.

If a later TFTP transfer is allocated at the same heap address (common after free+malloc of the same size) and the new transfer's offset matches saved_offset, get_block() returns previously cached file content from daemon->packet without reading the new client's file from disk. In a PXE environment this can substitute attacker-controlled file content for a victim's boot file.

The cache check compares only pointer identity and offset. It does not verify filename, inode, file descriptor, or client identity. daemon->srv_save is shared with DNS forwarding, so DNS activity overwrites the TFTP cache key and accidentally mitigates the bug in mixed DNS/TFTP deployments.

Compile-time gate: HAVE_TFTP is defined by default (src/config.h). Runtime gate: --enable-tftp. Exploitation is deterministic when DNS is inactive and clients do not negotiate TFTP options (the OACK path clears srv_save).

Affected versions: v2.92 through HEAD. Introducing commit: ee09f06 (Optimise tftp). Unaffected: v2.91 and earlier (no saved_offset prefetch cache).
Fix: Not yet available (reporter coordinating with upstream).
Reporter: Shubham Raj (Causal Security)
PSIRT Ticket: PSIRTSUPT-23743