Hello GNU tar maintainers, I would like to report what I believe is a previously undocumented security issue affecting GNU tar incremental extraction.
The issue has been reproduced on: - GNU tar 1.35 - current upstream HEAD (tested on 2026-07-03) - Ubuntu package 1.35+dfsg-4 Summary During incremental extraction, pathname bookkeeping becomes inconsistent after directory renaming performed through GNU.dumpdir processing. More specifically, delayed hardlink processing stores the original pathname in the delayed link list. When GNU.dumpdir later renames ancestor directories, the delayed metadata used for permissions and timestamps is updated, but the delayed hardlink source pathname is not updated accordingly. As a consequence, delayed hardlink creation may operate on stale pathnames instead of the logical filesystem state that exists after directory normalization. Root cause The issue appears to originate from the interaction between: - create_placeholder_file() - rename_directory() - fixup_delayed_set_stat() - apply_delayed_link() rename_directory() updates delayed_set_stat entries but does not update delayed_link.sources. Later, apply_delayed_link() resolves and applies hardlinks using stale pathnames. This creates a divergence between the internal logical extraction state and the actual filesystem layout. Experimental results The issue has been reproduced repeatedly under controlled laboratory conditions. Observed properties: - attacker-controlled file content; - object created outside the intended logical extraction subtree; - extraction completes successfully; - exit status is 0; - no stderr diagnostics are emitted; - resulting object shares the same inode as the attacker-controlled file created inside the archive. The behaviour has been reproduced consistently on all tested GNU tar versions listed above. Consumer analysis As part of impact assessment I evaluated classes of software invoking GNU tar for incremental restore operations. The analysis distinguishes between: - consumers that recreate the extraction tree between invocations (not compatible with this primitive); - consumers whose restore workflow repeatedly invokes GNU tar on the same restore directory without recreating the destination, making them architecturally compatible with the primitive. At this stage I am reporting the GNU tar defect itself rather than making vulnerability claims regarding downstream software. Available material I have prepared: - minimal reproducible archive; - deterministic laboratory environment; - execution logs; - syscall traces; - root-cause analysis; - candidate fix direction. I will be happy to provide all supporting material privately and assist with testing or validation. Please let me know your preferred way to exchange the reproduction archive and supporting evidence. Kind regards, Federico
gnu-tar-disclosure-package.tar.xz
Description: application/compressed
