On Thu, 2025-07-17 at 17:05 -0700, Kees Cook wrote: > > But I'm also not completely sure I've convinced myself that all the > > above discussion about allocated vs. used is really the _entire_ > > explanation for it being such a spectacular failure here. > > I think it's a big part of it -- having the counted member change after > initial assignment is even frowned upon by the compiler folks, but is > technically supported. Right. So since I wrote the above, I've come to think that while it'd almost certainly fix this issue, the num_channels had another side effect of validating the *read* side in cases like this. While we may allocate 25 channels, if we're only using 2 then reading the 10th would be a bug since it's not been initialized (OK, it's probably NULL, but still not filled to a valid value.) So in some way, you almost want to be able to separate the two and write __counted_by(write=n_alloc, read=n_used), but I guess I don't see compilers supporting that any time. I guess the only other way around it would be to re-allocate it all the time, but that's also annoying in other ways (possibly context, copying other large things in it, etc.) > Anyway, sorry again for the wasting of time of yours (and others) that I > caused with this -- I really wasn't expecting it to go that way, and it > hasn't been anywhere near as troublesome in other areas of the kernel, > so it took me by surprise. I have tried to chase down and fix the glitches > when I became aware of them, FWIW. Sure, I know, and thanks for that. > I'll see if I can write up some patches for comments like you suggest > above with good "proof" attached to them. :) Thanks, help re-reviewing these is much appreciated. johannes
