On 1/4/19 5:50 PM, Eric Blake wrote: >> hmm, as I understand, even if this compatibility exists, it's not a part >> of standard and nothing about off_t size in POSIX.. > > off_t allows you to run on older systems with 32-bit offsets and newer > systems with 64-bit offsets; but these days, even on 32-bit systems, we > compile qemu to always ask for 64-bit off_t. Using off_t instead of > int64_t is probably a separate cleanup, but one that may be worth making > prior to this patch, so I'll defer this one to my v3. > >> >> Moreover: what is the reason for using off_t in NBD code? We don't have it >> in NBD protocol, we don't have it in generic block layer interface. Isn't it >> always casted to int64_t or like this?
Thanks again for asking this question. In auditing the use of off_t, I found that 'qemu-nbd -P 1' happily tries to read beyond the bounds of the BDS. Thankfully, I can't find an exploit (escaped the CVE bullet - no DoS assertion, overlarge malloc, information leak, or other nasty problem), merely a permanent EIO down the road once the client tries to access advertised available bytes; but I'm also adding a patch to my v3 series that does sanity checking (as we should NEVER blindly trust values in a potentially-malicious image as being in bounds, so that clients can't even connect to such images in the first place). [I also think that qemu-nbd -P is seldom-used...] -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
