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,
