Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size

On Sat, Jul 18, 2026 at 10:07:30AM -0700, Carlos Bilbao wrote:
> On 7/17/26 22:29, Greg Kroah-Hartman wrote:
> 
> > On Fri, Jul 17, 2026 at 08:31:09PM -0700, Carlos Bilbao wrote:
> > > Historically, one of the biggest criticisms of coco, especially around
> > > device hardening, was that there were too many values that a
> > > malicious/buggy device could misreport, making it a losing battle. That is
> > > no longer the case with LLMs, and we have the advantage (and challenge) of
> > > open-source dev, which allows us to receive many of these fixes "for free".
> > > If others want to burn their tokens, let them :)
> > I have lots of tokens to burn :)
> > 
> > So along those lines, any suggestions on how best to fuzz these code
> > paths?  Any workloads you all use for testing that I can take advantage
> > of?
> 
> 
> We've the virtio-mem config struct layout and the kernel source, so for
> obvious fixes like a NULL check, static analysis is better than fuzzing.
> Claude took a few mins to find me two examples:
> 
> Patch 1: virtio-mem: reject non-power-of-two device_block_size
> This one is for virtio_mem_init() to check if
> !is_power_of_2(vm->device_block_size)
> 
> Patch 2: virto-mem: validate region_size and usable_region_size
> THis one checks region_size != 0 and vm->usable_reion_size >
> vm->region_size.
> 
> An endless factory of "silly" checks like these are low hanging fruit.

At the same time, these checks don't actually help within the coco
threat model, do they?

> Now, for harder bugs, looking around for fuzz options, VirtFuzz [1] looks
> like a great candidate for those interested in pursuing this direction.
> 
> 
> Their PoC fuzzes wireless/Bluetooth stack, but nothing our AI overlords
> can't quickly adapt for virtio-mem and other virtio drivers; the JSON
> definition to describe device behavior is easily extensible. Their threat
> model [2] describes an external attacker, but in the context of coco, the
> virtio device itself is the attacker.

What we need, however, is to exclude DoS attacks - these are outside the
threat model. If people try to address all DoS attacks uncritically we
just get a churn of changes which just might introduce issues of their
own.

Example:

	BUG_ON(!is_power_of_2(....));
panics, non exploitable.

	if(!is_power_of_2(....))
		goto error;

can become exploitable if the cleanup is done wrong.
		


> Here's a vibe coded PR of what I mean:
> 
> https://github.com/seemoo-lab/VirtFuzz/pull/7
> 
> CCed the creators/authors, thanks for open sourcing this!
> 
> Thanks,
> Carlos
> 
> [1] https://github.com/seemoo-lab/VirtFuzz
> 
> On 7/17/26 22:29, Greg Kroah-Hartman wrote:
> 
> > On Fri, Jul 17, 2026 at 08:31:09PM -0700, Carlos Bilbao wrote:
> > > Historically, one of the biggest criticisms of coco, especially around
> > > device hardening, was that there were too many values that a
> > > malicious/buggy device could misreport, making it a losing battle. That is
> > > no longer the case with LLMs, and we have the advantage (and challenge) of
> > > open-source dev, which allows us to receive many of these fixes "for free".
> > > If others want to burn their tokens, let them :)
> > I have lots of tokens to burn :)
> > 
> > So along those lines, any suggestions on how best to fuzz these code
> > paths?  Any workloads you all use for testing that I can take advantage
> > of?
> 
> 
> We've the virto-mem config struct layout and the kernel source, so for
> obvious fixes like a NULL check, static analysis is better than fuzzing.
> Claude took a few mins to find me two examples:
> 
> Patch 1: virtio-mem: reject non-power-of-two device_block_size
> This one is for virtio_mem_init() to check if
> !is_power_of_2(vm->device_block_size)
> 
> Patch 2: virto-mem: validate region_size and usable_region_size
> THis one checks region_size != 0 and vm->usable_reion_size >
> vm->region_size.
> 
> An endless factory of "silly" checks like these are low hanging fruit.
> 
> Now, for harder bugs, looking around for fuzz options, VirtFuzz [1] looks
> like a great candidate for those interested in pursuing this direction.
> 
> 
> Their PoC fuzzes wireless/Bluetooth stack, but nothing our AI overlords
> can't quickly adapt for virtio-mem and other virtio drivers; the JSON
> definition to describe device behavior is easily extensible. Their threat
> model [2] describes an external attacker, but in the context of coco, the
> virtio device itself is the attacker. Here's a vibe coded PR of what I mean:
> 
> https://github.com/seemoo-lab/VirtFuzz/pull/7
> 
> CCed the creators/authors, thanks for open sourcing this!
> 
> Thanks,
> Carlos
> 
> [1] https://github.com/seemoo-lab/VirtFuzz
> [2] https://www.computer.org/csdl/proceedings-article/sp/2024/313000a024/1RjEa0y9RMQ
> 
> 
> > thanks,
> > 
> > greg k-h
> 
> [2] https://www.computer.org/csdl/proceedings-article/sp/2024/313000a024/1RjEa0y9RMQ
> 
> 
> > 
> > thanks,
> > 
> > greg k-h