Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Carlos Bilbao
Date: Sat Jul 18 2026 - 13:07:51 EST
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 aroundI have lots of tokens to burn :)
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 :)
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.
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
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 aroundI have lots of tokens to burn :)
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 :)
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