On Mon, Apr 13, 2026 at 10:46:02AM -0300, Jason Gunthorpe wrote: > On Fri, Apr 10, 2026 at 10:29:45PM +0000, Long Li wrote: > > > On Sat, Mar 21, 2026 at 12:56:39AM +0000, Long Li wrote: > > > > > > > How we rephrase this in this way: the driver should not corrupt or > > > > overflow other parts of the kernel if its device is misbehaving (or > > > > has a bug). > > > > > > If we are going to do this CC hardening stuff I think I want to see a more > > > comphrensive approach, like if we detect an attack then the kernel > > > instantly > > > crashes or something. Or at least an approach in general agreed to by the > > > CC and > > > kernel community. > > > > > > Igoring the issue and continuing seems just wrong. > > > > > > This sprinkling of random checks in this series doesn't feel > > > comprehensive or > > > cohesive to me. > > > > > > Jason > > > > Can we follow the virtio BAD_RING()/vq->broken pattern in > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_ring.c#n57. > > > > Add a broken flag to mana_ib_dev. When any hardware response > > contains out-of-range values, mark the device broken and fail the > > operation - during probe this prevents device registration entirely, > > at runtime all subsequent operations return -EIO. > > If that's the plan I would think it should be struct device based, but > yeah, I'm more comfortable with this sort of direction as a CC > hardening plan. > Hi Jason,
Our team is not aligned with marking the device broken, after multiple discussions, since both the values that are received from hardware and stored in mana_ib_gd_query_adapter_caps are u32. I'm planning to send v3 as a non-hardening patch with only clamping the values at mana_ib_query_device to INT_MAX when out-of-bound. Your previous concerns: > “I'm also not convinced clamping to such a high value has any value > whatsoever, as it probably still triggers maths overflows elsewhere. I > think you should clamp to reasonable limits for your device if you want > to do this.” We plan to clamp it to INT_MAX since it is the max in props. > “There is no reason they should be signed, you should just fix the > type.” It is not allowed to change sign in props, so clamping is the best bet. Thanks, Vennela
