On 09.05.2018 00:14, Paolo Bonzini wrote: > From: Daniel P. Berrangé <berra...@redhat.com>
Here the accent is right ^ > The existing QemuOpts parsing code uses a fixed size 128 byte buffer > for storing the parameter keys. If a key exceeded this size it was > silently truncate and no error reported to the user. This behaviour was > reasonable & harmless because traditionally the key names are all > statically declared, and it was known that no code was declaring a key > longer than 127 bytes. This assumption, however, ceased to be valid once > the block layer added support for dot-separate compound keys. This > syntax allows for keys that can be arbitrarily long, limited only by the > number of block drivers you can stack up. With this usage, silently > truncating the key name can never lead to correct behaviour. > > Hopefully such truncation would turn into an error, when the block code > then tried to extract options later, but there's no guarantee that will > happen. It is conceivable that an option specified by the user may be > truncated and then ignored. This could have serious consequences, > possibly even leading to security problems if the ignored option set a > security relevant parameter. > > If the operating system didn't limit the user's argv when spawning QEMU, > the code should honour whatever length arguments were given without > imposing its own length restrictions. This patch thus changes the code > to use a heap allocated buffer for storing the keys during parsing, > lifting the arbitrary length restriction. > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> But this one got mojibaked -------^ Thomas
