Hi Diederik,
On Sun, Nov 20, 2022 at 04:26:45PM +0100, Diederik de Haas wrote:
> Control: notfound -1 4.9.88-1+deb9u1
> Control: found -1 4.9.88-1
Hmm this one I do not understand, as 4.9.88-1+deb9u1 was a very
targetted fix for two CVEs and reverting the "random: fix crng_ready()
test" changes re-opening CVE-2018-1108.
> On zondag 20 november 2022 13:55:09 CET Salvatore Bonaccorso wrote:
> > Seems the BSP was productive :).
>
> Yeah, once I set up the VM and created the script, it was actually quite easy.
:-)
> > If you have spare cycles, might you
> > check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
> > in 5.16-rc4 is the commit we are searching?
> > That one was backported to the 5.10.y series in 5.10.84 and in 5.15.y series
> > in 5.15.7 which would fall into your found ranges as well.
>
> IOW: that's your educated guess a git bisect could turn up?
Not really. I was more looking at between versions you are not able to
reproduce the issue, looking through the upstream changes commits and
noticing that dacb5d8875cc ("tcp: fix page frag corruption on page
fault") mentions:
[...]
Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.
[...]
and then noticing that the upstrema commit was backported to 5.10.84
an 5.15.7, which fall exactly in the ranges you have the switch of
result.
> I can try that*, although I'm not clear onto what I should apply it.
> Should I apply it to linux/5.10.70-1 or 5.10.46-4 f.e.? Or onto an entirely
> different version?
Basically I wonder if c6f340a331fb72e5ac23a083de9c780e132ca3ae in
5.10.84 fixes the issue, and
c6f340a331fb72e5ac23a083de9c780e132ca3ae~1 still would show the
problem.
Alterntively if 5.10.70-1 + commit fixes the issue.
Regards,
Salvatore
