> - How the issue was discovered, e.g. hit in production, hit during
> development, syzbot report, manual code inspection, LLM or static
> analysis tool scan.
Sabrina reported the splice(2) false EOF fixed in patch 3 while
reviewing commit 3be28e2c9cd0 ("net/tls: Consume empty data records
in tls_sw_read_sock()"):
https://lore.kernel.org/netdev/akaoXcfamBp8_mYe@krikkit/
Sashiko's review of that patch flagged the same defect, and also
the rx_list growth under MSG_PEEK fixed in patch 5. Its review of
the read_sock series I posted on July 20 flagged the missing signal
check in tls_sw_recvmsg() fixed in patch 2.
The defects fixed in patches 1 and 4 were found by an LLM audit and
review of the TLS read code paths.
> - Whether the issue was actually triggered, or is only theoretical
> (e.g. found by code inspection). If it was triggered please include
> the symptoms, like the stack trace or error messages.
None of these was hit in production, so there is no stack trace or
error message to include.
The selftests in this series reproduce these two: On an unfixed
kernel, splice(2) returns zero when it reaches a zero-length record
(patches 3 and 6); and a splice from a nonblocking socket without
SPLICE_F_NONBLOCK sleeps until the harness timeout (patches 4 and 8).
The fixes in patches 1, 2, and 5 have not been reproduced because
these need a peer that streams zero-length records without pause.
I'll update the commit messages I'm carrying locally so subsequent
postings will carry this information.
--
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)
