Em Fri, 18 Oct 2024 07:37:52 -0700
Kees Cook <kees@xxxxxxxxxx> escreveu:
> On October 18, 2024 4:44:20 AM PDT, Philipp Stanner <pstanner@xxxxxxxxxx> wrote:
> >On Fri, 2024-10-18 at 07:53 +0200, Mauro Carvalho Chehab wrote:
> >> fepriv->auto_sub_step is unsigned. Setting it to -1 is just a
> >> trick to avoid calling continue, as reported by Coverity.
> >>
> >> It relies to have this code just afterwards:
> >>
> >> if (!ready) fepriv->auto_sub_step++;
> >>
> >> Simplify the code by simply setting it to zero and use
> >> continue to return to the while loop.
> >>
> >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> >
> >Oh wow, back to the big-bang-commit ^^'
> >
> >So is this a bug or not? It seems to me that the uint underflows to
> >UINT_MAX, and then wrapps around to 0 again through the ++..
> >
> >I take the liberty of ++CCing Kees, since I heard him talk a lot about
> >overflowing on Plumbers.
> >
> >If it's not a bug, I would not use "Fixes". If it is a bug, it should
> >be backported to stable, agreed?
There is a long thread about Fixes: tag at ksummit ML.
https://lore.kernel.org/all/20240714192914.1e1d3448@xxxxxxxxxxxxxxxxxx/T/
My conclusions for it is that:
1. Fixes: != Cc: stable.
This is even somewhat stated at
Documentation/process/stable-kernel-rules.rst when it defines additional
rules for Cc: stable;
2. As result of (1), all Cc: stable need fixes, but not all fixes: need
a Cc: stable. Btw, I double-checked it with a -stable maintainer
(Greg);
3. It seems that most of people at ksummit discussion (including me)
use Fixes: when the patch is not doing an improvement.
> >Plus, is there a report-link somewhere by Coverty that could be linked
> >with "Closes: "?
Coverity issues are not publicly visible (and IMO it shouldn't).
We should not add closes: to something that only the ones with access
to it may see.
> Yeah, this is "avoid currently harmless overflow" fix. It is just avoiding depending on the wrapping behavior, which is an improvement but not really a "bug fix"; more a code style that will keep future work of making the kernel wrapping-safe.
It is a fix in the sense that it solves an issue reported by Coverity.
> >> if (!ready) fepriv->auto_sub_step++;
> >
>
> But this change seems incomplete. The above line is no longer needed.
Yes, this is now a dead code.
> And I actually think this could be refractored to avoid needing "ready" at all?
Yeah, it sounds a good idea to place the zig-zag drift calculus on a
separate function, doing some cleanups in the process.
I'll add it to my todo list.
Thanks,
Mauro
