From 0ac7291ca51f87df8022da0f66178546e855701a Mon Sep 17 00:00:00 2001 From: Ethan Graham Date: Thu, 18 Sep 2025 14:13:45 +0000 Subject: prog: fix syz_kfuzztest_run allocation strategy Previously, the generated KFuzzTest programs were reusing the address of the top-level input struct. A problem could arise when the encoded blob is large and overflows into another allocated region - this certainly happens in the case where the input struct points to some large char buffer, for example. While this wasn't directly a problem, it could lead to racy behavior when running KFuzzTest targets concurrently. To fix this, we now introduce an additional buffer parameter into syz_kfuzztest_run that is as big as the maximum accepted input size in the KFuzzTest kernel code. When this buffer is allocated, we ensure that we have some allocated space in the program that can hold the entire encoded input. This works in practice, but has not been tested with concurrent KFuzzTest executions yet. --- prog/kfuzztest.go | 3 +++ 1 file changed, 3 insertions(+) (limited to 'prog/kfuzztest.go') diff --git a/prog/kfuzztest.go b/prog/kfuzztest.go index 1ff65e29a..dacd54885 100644 --- a/prog/kfuzztest.go +++ b/prog/kfuzztest.go @@ -22,6 +22,9 @@ const ( // x86_64, so we hardcode it for now. A more robust solution would involve // reading this from the debugfs entry at boot before fuzzing begins. kFuzzTestMinalign uint64 = 8 + + // Maximum input size accepted by the KFuzzTest kernel module. + KFuzzTestMaxInputSize uint64 = 64 << 10 ) func kFuzzTestWritePrefix(buf *bytes.Buffer) { -- cgit mrf-deployment