Control: found -1 4.9.88-1+deb9u1
Control: notfound -1 4.9.88-1
Hi Salvatore,
On zondag 20 november 2022 16:38:25 CET Salvatore Bonaccorso wrote:
> 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.
Oh, I thought that the +debXYZ thing confuses the bug tracker and therefor
shouldn't be there*. All the notfound/found versions I reported were tested
with a backports kernel, so +debXYZ, but I marked them without that suffix.
I thought that the 4.9.88-1+deb9u1 should therefor be corrected to be without
the suffix.
(I don't see how that affects the CVEs though as that has nothing to do with
this bug? But it's (very) possible I'm too tired atm)
*) The dependency graph at the top doesn't show the 4.9 version; later I
realized that another 4.9 version was already there and that wasn't reflected
in that graph either, so I reverted the change.
I don't know if the other found/notfound versions should be corrected.
> > 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.
That was what I actually meant, but I now realize that git bisect finds the
cause while your educated guess is about the solution :-)
> > 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.
It won't be tonight, but I'll likely try that :-)
Cheers,
DiederikAttachment:
signature.asc
Description: This is a digitally signed message part.