On 26.09.23 14:05, Peter Maydell wrote:
On Mon, 25 Sept 2023 at 20:43, Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxxx> wrote:Coverity doesn't like when the value with unchecked bounds that comes from fd is used as length for IO or allocation. And really, that's not a good practice. Let's introduce at least an empirical limits for these values. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxxx> --- accel/kvm/kvm-all.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index ff1578bb32..6d0ba7d900 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -3988,6 +3988,9 @@ typedef struct StatsDescriptors { static QTAILQ_HEAD(, StatsDescriptors) stats_descriptors = QTAILQ_HEAD_INITIALIZER(stats_descriptors); + +#define KVM_STATS_QEMU_MAX_NAME_SIZE (1024 * 1024) +#define KVM_STATS_QEMU_MAX_NUM_DESC (1024)These seem arbitrary. Why these values in particular? Does the kernel have any limitation on the values it passes us?
Documentation doesn't say about limits
Do we have any particular limit on what we can handle?
Hmm. At least, we don't arithmetic operations with these values to overflow. But in this case g_malloc0_n should crash anyway. So we may rely on g_malloc0_n as on assertion that the values are good enough and further doubts are false-positives. Will drop this patch. -- Best regards, Vladimir
