8:50 a.m.
On Thu, Feb 10, 2022 at 09:38:30AM +0000, Richard W.M. Jones wrote:
On Wed, Feb 09, 2022 at 04:07:26PM -0600, Eric Blake wrote:
> + "set_pread_initialize", {
> + default_call with
> + args = [Bool "request"]; ret = RErr;
> + shortdesc = "control whether libnbd pre-initializes read buffers";
> + longdesc = "\
> +By default, libnbd will pre-initialize the contents of a buffer
> +passed to calls such as L<nbd_pread(3)> to all zeroes prior to checking
> +for any other errors, so that even if a client application passed in an
> +uninitialized buffer but fails to check for errors, it will not result
> +in a potential security risk caused by an accidental leak of prior heap
> +contents. However, for a client application that has audited that an
> +uninitialized buffer is never dereferenced, or which performs its own
> +pre-initialization, libnbd's sanitization efforts merely pessimize
> +performance.
> +
> +Calling this function with C<request> set to false tells libnbd to
> +skip the buffer initialization step in read commands.";
> + see_also = [Link "get_pread_initialize";
> + Link "set_strict_mode";
> + Link "pread"; Link "pread_structured"; Link
"aio_pread";
> + Link "aio_pread_structured"];
> + };
Could it be worth mentioning CVE-2022-0485 by name in the text here?
And/or linking to:
https://listman.redhat.com/archives/libguestfs/2022-February/msg00104.html
Good idea, I went with:
diff --git i/generator/API.ml w/generator/API.ml
index 9b7eb545..aaba9951 100644
--- i/generator/API.ml
+++ w/generator/API.ml
@@ -784,14 +784,19 @@ "set_pread_initialize", {
shortdesc = "control whether libnbd pre-initializes read buffers";
longdesc = "\
By default, libnbd will pre-initialize the contents of a buffer
-passed to calls such as L<nbd_pread(3)> to all zeroes prior to checking
-for any other errors, so that even if a client application passed in an
-uninitialized buffer but fails to check for errors, it will not result
-in a potential security risk caused by an accidental leak of prior heap
-contents. However, for a client application that has audited that an
-uninitialized buffer is never dereferenced, or which performs its own
-pre-initialization, libnbd's sanitization efforts merely pessimize
-performance.
+passed to calls such as L<nbd_pread(3)> to all zeroes prior to
+checking for any other errors, so that even if a client application
+passed in an uninitialized buffer but fails to check for errors, it
+will not result in a potential security risk caused by an accidental
+leak of prior heap contents (see CVE-2022-0485 in
+L<libnbd-security(3)> for an example of a security hole in an
+application built against an earlier version of libnbd that lacked
+consistent pre-initialization). However, for a client application
+that has audited that an uninitialized buffer is never dereferenced,
+or which performs its own pre-initialization, libnbd's sanitization
+efforts merely pessimize performance (although the time spent in
+pre-initialization may pale in comparison to time spent waiting on
+network packets).
Calling this function with C<request> set to false tells libnbd to
skip the buffer initialization step in read commands.";
Anyway the whole patch series looks good, so:
Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com>
Series is now checked in with amendments, as ab52914b..e0953cb7
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org