Cat's out of the bag: Rich's fuzzer run found not one, but two
independent assertion failures that a malicious server could trigger
in my recent 64-bit extension code additions. What's more, in the
process of fixing them, we've discovered another long-standing issue
where nbd_get_size() returns confusing results compared to its
documentation, when talking to an odd server that reports a really
large export size.
After off-list discussion between Rich, Laszlo, and myself, we didn't
think an embargoed CVE against libnbd is necessary (the assertion
failures only happen to unstable releases, and the nbd_get_size()
misbehavior does not happen with normal servers and has been in place
since v1.0, so it is nothing new), so I am posting the series now for
public review. But we will still be reaching out to secalert for
their opinion (it may be that they still see a low-priority exploit in
an app that gets confused when trying to use a negative size as a loop
bound, for example). Once they answer, and regardless of whether we
end up doing a libnbd CVE after all, I will follow up to the mailing
list with a security incident (client apps that demand a positive
export size should probably favor nbd_get_size()<0 over
nbd_get_size()==-1).
Eric Blake (6):
states: Tweak comment in OPT_GO state handler
fuzzing: Disable client-side strictness checks
api: Sanitize sizes larger than INT64_MAX
block_status: Fix assertion with large server size
block_status: Fix assertion on bad 64-bit block status reply
info: Tolerate missing size
generator/API.ml | 6 +++-
generator/states-newstyle-opt-go.c | 5 ++-
generator/states-reply-chunk.c | 50 ++++++++++++++++--------------
generator/C.ml | 2 +-
lib/flags.c | 6 ++++
fuzzing/libnbd-fuzz-wrapper.c | 5 ++-
info/show.c | 25 ++++++++-------
7 files changed, 60 insertions(+), 39 deletions(-)
--
2.41.0