[PATCH 1/1] usb: acpi: fix undefined behavior in USB_ACPI_LOCATION_VALID

[PATCH 1/1] usb: acpi: fix undefined behavior in USB_ACPI_LOCATION_VALID

[Igor Cudnik]

USB_ACPI_LOCATION_VALID uses a signed left shift into the sign
bit. Shifting a signed value into the sign bit is undefined behavior.
Use BIT(31) instead.

Found by cppcheck:
      drivers/usb/core/usb-acpi.c:221:24: error:
      Shifting signed 32-bit value by 31 bits is undefined behaviour
      [shiftTooManyBitsSigned]

Fixes: f3ac348e6e045 ("usb: usb-acpi: Set port connect type of not connectable ports correctly")
Signed-off-by: Igor Cudnik <igor@its.rel.pl>
---
 drivers/usb/core/usb-acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 489dbdc96f94..583aca6d7669 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -197,7 +197,7 @@ static int usb_acpi_add_usb4_devlink(struct usb_device *udev)
  * Private to usb-acpi, all the core needs to know is that
  * port_dev->location is non-zero when it has been set by the firmware.
  */
-#define USB_ACPI_LOCATION_VALID (1 << 31)
+#define USB_ACPI_LOCATION_VALID BIT(31)
 
 static void
 usb_acpi_get_connect_type(struct usb_port *port_dev, acpi_handle *handle)
-- 
2.53.0

Re: [PATCH 1/1] usb: acpi: fix undefined behavior in USB_ACPI_LOCATION_VALID

[Greg KH]

On Tue, May 26, 2026 at 07:43:37PM +0200, Igor Cudnik wrote:
> USB_ACPI_LOCATION_VALID uses a signed left shift into the sign
> bit. Shifting a signed value into the sign bit is undefined behavior.
> Use BIT(31) instead.

SHouldn't this be UBIT(31) instead, if you were really worried about
this shift?

> 
> Found by cppcheck:
>       drivers/usb/core/usb-acpi.c:221:24: error:
>       Shifting signed 32-bit value by 31 bits is undefined behaviour

Is this really a bug?  Look at how this is used, is the generated code
"wrong"?

>       [shiftTooManyBitsSigned]
> 
> Fixes: f3ac348e6e045 ("usb: usb-acpi: Set port connect type of not connectable ports correctly")

Is this fixing a real bug?  Or just papering over a buggy tool?

thanks,

greg k-h