diff --git a/common b/common index 0a231b3e6..201632e4a 160000 --- a/common +++ b/common @@ -1 +1 @@ -Subproject commit 0a231b3e68bbf229cef706e86bef37b81debacb9 +Subproject commit 201632e4a78c1f591ea2d9038bd22f738642cf5c diff --git a/docs/guestfs-security.pod b/docs/guestfs-security.pod index 9ceef5623..efa35b29d 100644 --- a/docs/guestfs-security.pod +++ b/docs/guestfs-security.pod @@ -406,6 +406,34 @@ The libvirt backend is not affected. The solution is to update qemu to a version containing the fix (see L). +=head2 CVE-2022-2211 + +L + +The C function in F collects +those I<--key> options from the command line into a new array that match +a particular block device that's being decrypted for inspection. The +function intends to size the result array such that potentially all +I<--key> options, plus a terminating C element, fit into it. The +code mistakenly uses the C macro instead of C, and therefore +only one element is allocated before the C terminator. + +Passing precisely two I<--key ID:...> options on the command line for +the encrypted block device C causes C to overwrite the +terminating C, leading to an out-of-bounds read in +C, file F. + +Passing more than two I<--key ID:...> options on the command line for +the encrypted block device C causes C itself to perform +out-of-bounds writes. The most common symptom is a crash with C +later on. + +This issue affects -- broadly speaking -- all libguestfs-based utilities +that accept I<--key>, namely: C, C, C, +C, C, C, C, +C, C, C, C, +C, C, C. + =head1 SEE ALSO L,