linux-kernel - struct hci_dev::quirks is running out of bits on 32-bit platforms

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: <22185131.4csPzL39Zc@n9w6sw14>
Date: Mon, 14 Jul 2025 19:09:10 +0200
From: Christian Eggers <ceggers@...i.de>
To: <linux-bluetooth@...r.kernel.org>
CC: <linux-kernel@...r.kernel.org>
Subject: struct hci_dev::quirks is running out of bits on 32-bit platforms

I just tried to introduce another quirk for Realtek Bluetooth controllers 
when I recognized that the underlying data type (unsigned long) has already
run out available bits on system where sizeof(unsigned long) == 4.
The number of entries in the (anonymous) quirks enum has already reached 34 
in the latest kernels.

My first temptation was to simply change the data type to something like __u64,
but this is not as easy as it seems. The test_bit() macro used almost everywhere
for assigning quirks is guaranteed to be atomic and my platform (ARMv7) seems
not to have support for atomic operations on __u64.

I mainly see two options:

1. Introducing a 'quirks2' member (bad)

This obviously would work, but requires another enum and will (I think)
introduce stupid bugs if the wrong quirks member is exercised.

2. Switch to using __64 with non atomic operations

About 99% of write accesses to the quirks member happen from probe() or
setup() routines which should (I hope) not allow simultaneous access from other
contexts. I found 2 exceptions (as of linux-6.12):

a. btusb_setup_qca() is called from 'struct hci_dev::open()' (maybe uncritical).
b. Two quirks (strict_duplicate_filter, simultaneous_discovery) can be toggled 
   via debugfs.

So it looks like using non atomic operations can also introduce trouble if
not well reviewed. But as the 'strict_duplicate_filter' and 
'simultaneous_discovery' quirks are only used at very few locations, maybe
these should be moved to a new member for "atomic quirks", allowing to
convert the remaining ones to non atomic.

Are there any alternatives? Anything I missed?

regards,
Christian