lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220411211411.GA2796005@jaehee-ThinkPad-X1-Extreme>
Date:   Mon, 11 Apr 2022 17:14:11 -0400
From:   Jaehee Park <jhpark1013@...il.com>
To:     Johan Hovold <johan@...nel.org>, Alex Elder <elder@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        greybus-dev@...ts.linaro.org, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, outreachy@...ts.linux.dev,
        Jaehee Park <jhpark1013@...il.com>
Subject: [PATCH] staging: greybus: replace zero-element array with
 flexible-array

Zero-length and one-element arrays are deprecated. Flexible-array
members should be used instead. Flexible-array members are
recommended because this is the way the kernel expects dynamically
sized trailing elements to be declared.
Refer to Documentation/process/deprecated.rst.

Change the zero-length array, buf, in the struct 
gb_usb_hub_control_response to a flexible array. And add wLength as a 
member of the struct so that the struct is not a zero-sized struct.

Issue found by flexible_array coccinelle script.

Signed-off-by: Jaehee Park <jhpark1013@...il.com>
---

I have a question for the authors: 
I saw a fixme comment in the hub_control function in usb.c:
/ FIXME: handle unspecified lengths /

I was wondering why this comment was left there?

In this patch, I'm using this struct:

struct gb_usb_hub_control_response {
    __le16 wLength;
    u8 buf[];
};

And instead of using response_size, I'm doing this:

struct gb_usb_hub_control_response *response;
And using sizeof(*response) as the input to gb_operation_create.

Would the flexible array address the handling of unspecified lengths 
issue (in the fixme comment)?


 drivers/staging/greybus/usb.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c
index 8e9d9d59a357..d0b2422401df 100644
--- a/drivers/staging/greybus/usb.c
+++ b/drivers/staging/greybus/usb.c
@@ -27,7 +27,8 @@ struct gb_usb_hub_control_request {
 };
 
 struct gb_usb_hub_control_response {
-	u8 buf[0];
+	__le16 wLength;
+	u8 buf[];
 };
 
 struct gb_usb_device {
@@ -102,16 +103,14 @@ static int hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex,
 	struct gb_operation *operation;
 	struct gb_usb_hub_control_request *request;
 	struct gb_usb_hub_control_response *response;
-	size_t response_size;
 	int ret;
 
 	/* FIXME: handle unspecified lengths */
-	response_size = sizeof(*response) + wLength;
 
 	operation = gb_operation_create(dev->connection,
 					GB_USB_TYPE_HUB_CONTROL,
 					sizeof(*request),
-					response_size,
+					sizeof(*response),
 					GFP_KERNEL);
 	if (!operation)
 		return -ENOMEM;
-- 
2.25.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ