Re: [PATCH 0/7] crypto: Proper Initialization of `struct skcipher_walk` in x86 Glue Files

[Yuran Pereira]

Hey Herbert,
On Thu, Nov 02, 2023 at 12:30:44PM +0800, Herbert Xu wrote:
> On Wed, Nov 01, 2023 at 09:20:43PM -0700, Eric Biggers wrote:
> >
> > Updating all callers of skcipher_walk_virt() seems like the wrong approach.
> > Shouldn't skcipher_walk_virt() be fixed to initialize the flags to 0 instead?
> 
> The bits of the flags that are used are initialised in skcipher_walk_next.
>
I noticed that, but since skcipher_walk_first can return with failure, there seems
to be a chance that those bits are never initialized.
> > Also, does this fix affect any behavior, or is it just to fix a KMSAN warning?
> > It needs to be fixed either way, but it's helpful to understand the effect of
> > the fix so that people can decide whether it needs to be backported or not.
> 
> Does this actually trigger a KMSAN warning? If so I'd like to see
> it.  If it's just a static analyser then I'm not applying this.
No, there is no KMSAN warning. As I mentioned in the individual patches,
they're addressing "coverity" reports (so yes, static analyser).

Initially it did look like a false positive, but upon seeing that 
skcipher_walk_first can return without ever calling skcipher_walk_next
I thought that there might be an off-chance that skcipher_walk_virt
returns without ever initializing those bits of the flag... hence this
patch set.

PS: I just saw Eric's reply, 
> > Updating all callers of skcipher_walk_virt() seems like the wrong approach.

and realized that maybe my approach is in fact an overkill. Maybe simply initializing 
the flags would indeed suffice.

Thanks,