On Tue, Nov 5, 2024 at 12:44 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > Hi; Coverity raises a couple of potential issues with the > read_eif_file() function in this commit, which are both > "Coverity assumes the file we're reading is untrusted and is > unsure that we're correctly sanitizing data from it before use". > Could somebody who understands the use case here check whether > these need addressing?
Both are reasonable to fix, even if the use case would not make them security sensitive. I'll prepare and send a patch. Paolo > CID 1564855 "overflowed integer argument" -- > basically eif_header.section_offsets[i] is from the data > file and is a uint64_t, but we pass it to fseek() in > read_eif_file. fseek() takes a signed offset, so if the > section_offset in the file header is very large it will > be unexpectedly treated as a negative number. > > CID 1564859 "untrusted value as argument" -- > in the "default" case for handling a section type > we call g_malloc() with the uint64_t size from the header. > If the file data is bogus we might try to allocate a > huge amount of memory, which will cause g_malloc() to > kill QEMU. > > thanks > -- PMM >
