apex-security-research <[email protected]> writes: > Collin, one fact so you do not have to guess at it. > > That patch was written with model assistance. It is not a clean-authored > diff and > your reading of the copyright position is the right one, so writing your own > from > the description is the shortest path to a fix. Use my analysis and the > reproducer > freely; the credit for the defect itself is Vahagn Vardanian's. > > No copyright assignment is on offer from me today, so please do not wait on > one. > > If it helps, I will test whatever you and the maintainers settle on against > the > desynchronised-map case and report back in one paragraph.
Thanks for the clarification. Your patch is pretty short, though. If I were to write code to acheive the same behavior, it likely would look the same or very similar to it. I do wonder if it is the correct fix though. E.g., I notice using a archive that reproduces the issue, 'bsdtar' will list and extract the same files. Collin > > Apex Security Research > [email protected] > > > > > > Sent with Proton Mail secure email. > > On Friday, November 6th, 2026 at 9:40 AM, Collin Funk > <[email protected]> wrote: > >> Hi Pavel, >> >> Pavel Cahyna <[email protected]> writes: >> >> > I saw your oss-security post and thank you a lot for the analysis. >> > >> > While the report contained a ton of slop, this part was unfortunately >> > real (although written in a too grandiose way, i.e. claiming a RCE). I >> > let AI generate a reproducer (while AI reports are often slop, it is >> > usually pretty good at writing reproducers) and verified it works before >> > assigning the CVE. See: >> > /tmp/test_extract$ tar -tf ~/miscsrc/tar/exploit.tar >> > .cache >> > .gitignore >> > /tmp/test_extract$ tar -tvf ~/miscsrc/tar/exploit.tar >> > -rw-r--r-- 0/0 4096 1970-01-01 01:00 .cache >> > -rw-r--r-- 0/0 1024 1970-01-01 01:00 .gitignore >> > /tmp/test_extract$ tar -xvf ~/miscsrc/tar/exploit.tar >> > .cache >> > Makefile >> > /tmp/test_extract$ ls -A >> > .cache Makefile >> >> Thanks! By the way, I realize now my previous message may have sounded >> rude/accusatory. I've always had good experiences with Red Hat's >> security team, so I assumed you'd verified it and did not mean to imply >> otherwise, but I wanted to confirm. >> >> I've also noticed LLMs quickly claiming RCEs. In this case, I disagree >> with that because it requires you to invoke 'make' on an unknown >> Makefile. In a bug-free world, a malicious maintainer could easily just >> write a malicious Makefile and distribute it, and that very obviously >> wouldn't be considered an RCE. I assume that is similar to your >> rationale as well. >> >> Regarding your other comments on LLMs, I certainly agree. We signed GNU >> coreutils for Anthropic's OSS scanner. I pretty much just look at the >> reproducers and maybe the first paragraph of the summary, instead of >> wasting my time reading the overly long essays accompanying them. That >> has been a pretty effective strategy so far, at least. >> >> I suspect Sergey and Paul will want to accept an LLM-generated patch for >> copyright purposes. I'll see if I can write one based on the problem >> description this weekend for them to review. >> >> Thank you both for the report and analysis, >> Collin >>
