Siddhesh Poyarekar

This has been inexplicably reported as a security issue and has a CVE number assigned. Maybe cppcheck should consider adding a security policy document that describes what could conceivably be considered a security issue so that such useless CVEs don't waste everyone's time. I had contributed a security policy here for yasm, which could be adapted for cppcheck: https://github.com/yasm/yasm/blob/master/SECURITY.md

Thanks to Martin's reduced reproducer in the gcc bug[1], I can now see what's going on. The trouble is that gcc is unable to associate the reallocation in: p = AGREALOC(VOIDP(base_ctx), dataSize + 4 + sizeof(*base_ctx), "expand f buf"); with pzData when p == base_ctx because the pointer is not explicitly updated. This happens to work with the glibc malloc implementation but strictly speaking, the comparison if (p != base_ctx) { is invoking undefined behaviour as the C standard states that the pointer...

That use definitely looks a bit odd; (char *)(base_ctx + 1) is actually not just 1 byte off, it's sizeof (scan_ctx_t) off, leading to fread going beyond bounds before sizeLeft is 0. As an aside, it seems like the code is looking to use scan_ctx_t with a flex array at the end, so it might make sense to simply add a char data[]; at the end of that struct.

That use definitely looks a bit odd; (char *)(base_ctx + 1) is actually not just 1 byte off, it's sizeof (scan_ctx_t) off, leading to fread going beyond bounds before sizeLeft is 0. As an aside, it seems like the code is looking to use scan_ctx_t with a flex array at the end, so it might make sense to simply add a char data[]; at the end of that struct.