> 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. Long
