As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.
In "kzalloc()", the z is meaningful and an important part of what the
caller wants.
In "kzfree()", the z is actively detrimental, because maybe in the
future we really _might_ want to use that "memfill(0xdeadbeef)" or
something. The "zero" part of the interface isn't even _relevant_.
The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.
Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.
The renaming is done by using the command sequence:
git grep -w --name-only kzfree |\
xargs sed -i 's/kzfree/kfree_sensitive/'
followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.
[[email protected]: fs/crypto/inline_crypt.c needs linux/slab.h]
[[email protected]: fix fs/crypto/inline_crypt.c some more]
Suggested-by: Joe Perches <[email protected]>
Signed-off-by: Waiman Long <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: David Howells <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: "Jason A . Donenfeld" <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
net/bluetooth/sco.c: In function ‘sco_sock_setsockopt’:
net/bluetooth/sco.c:862:3: error: cannot convert to a pointer type
862 | if (get_user(opt, (u32 __user *)optval)) {
| ^~
Signed-off-by: David S. Miller <[email protected]>
Johan Hedberg says:
====================
pull request: bluetooth-next 2020-07-31
Here's the main bluetooth-next pull request for 5.9:
- Fix firmware filenames for Marvell chipsets
- Several suspend-related fixes
- Addedd mgmt commands for runtime configuration
- Multiple fixes for Qualcomm-based controllers
- Add new monitoring feature for mgmt
- Fix handling of legacy cipher (E4) together with security level 4
- Add support for Realtek 8822CE controller
- Fix issues with Chinese controllers using fake VID/PID values
- Multiple other smaller fixes & improvements
====================
Signed-off-by: David S. Miller <[email protected]>
The flag CRYPTO_ALG_INTERNAL is not meant to be used outside of
the Crypto API. It isn't needed here anyway.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Increment the mgmt revision due to the recently added new commands.
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
When an LE connection is requested and an RPA update is needed via
hci_connect_le_scan, the default scanning parameters are used rather
than the connect parameters. This leads to significant delays in the
connection establishment process when using lower duty cycle scanning
parameters.
The patch simply looks at the pended connection list when trying to
determine which scanning parameters should be used.
Before:
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
#378 [hci0] 1659.247156
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
PHYs: 0x01
Entry 0: LE 1M
Type: Passive (0x00)
Interval: 367.500 msec (0x024c)
Window: 37.500 msec (0x003c)
After:
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
#39 [hci0] 7.422109
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
PHYs: 0x01
Entry 0: LE 1M
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 60.000 msec (0x0060)
Signed-off-by: Alain Michaud <[email protected]>
Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Yu Liu <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
This patch adds support to enable the use of RPA Address resolution
using expermental feature mgmt command.
Signed-off-by: Sathish Narasimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Enable RPA timeout during bluetooth initialization.
The RPA timeout value is used from hdev, which initialized from
debug_fs
Signed-off-by: Sathish Narasimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
In this patch if le_create_conn process is started restrict to
disable address resolution and same is disabled during
le_enh_connection_complete
Signed-off-by: Sathish Narasimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When address resolution is enabled and set_privacy is enabled let's
use own address type as 0x03
Signed-off-by: Sathish Narasimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When using controller based address resolution, then the new address
types 0x02 and 0x03 are used. These types need to be converted back into
either public address or random address types.
This patch is specially during LE_CREATE_CONN if using own_add_type as 0x02
or 0x03.
Signed-off-by: Sathish Narasimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When the whitelist is updated, then also update the entries of the
resolving list for devices where IRKs are available.
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sathish Narsimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When the LL Privacy support is available, then as part of enabling or
disabling passive background scanning, it is required to set up the
controller based address resolution as well.
Since only passive background scanning is utilizing the whitelist, the
address resolution is now bound to the whitelist and passive background
scanning. All other resolution can be easily done by the host stack.
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sathish Narsimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When using controller based address resolution, then the new address
types 0x02 and 0x03 are used. These types need to be converted back into
either public address or random address types.
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sathish Narsimman <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
The original return is NOTIFY_STOP, but notifier_call_chain would stop
the future call for register_pm_notifier even registered on other Kernel
modules with the same priority which value is zero.
Signed-off-by: Max Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
For some reason they tend to squat on the very first CSR/
Cambridge Silicon Radio VID/PID instead of paying fees.
This is an extremely common problem; the issue goes as back as 2013
and these devices are only getting more popular, even rebranded by
reputable vendors and sold by retailers everywhere.
So, at this point in time there are hundreds of modern dongles reusing
the ID of what originally was an early Bluetooth 1.1 controller.
Linux is the only place where they don't work due to spotty checks
in our detection code. It only covered a minimum subset.
So what's the big idea? Take advantage of the fact that all CSR
chips report the same internal version as both the LMP sub-version and
HCI revision number. It always matches, couple that with the manufacturer
code, that rarely lies, and we now have a good idea of who is who.
Additionally, by compiling a list of user-reported HCI/lsusb dumps, and
searching around for legit CSR dongles in similar product ranges we can
find what CSR BlueCore firmware supported which Bluetooth versions.
That way we can narrow down ranges of fakes for each of them.
e.g. Real CSR dongles with LMP subversion 0x73 are old enough that
support BT 1.1 only; so it's a dead giveaway when some
third-party BT 4.0 dongle reuses it.
So, to sum things up; there are multiple classes of fake controllers
reusing the same 0A12:0001 VID/PID. This has been broken for a while.
Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891
IC markings on 0x7558: FR3191AHAL 749H15143 (???)
https://bugzilla.kernel.org/show_bug.cgi?id=60824
Fixes: 81cac64ba2 (Deal with USB devices that are faking CSR vendor)
Reported-by: Michał Wiśniewski <[email protected]>
Tested-by: Mike Johnson <[email protected]>
Tested-by: Ricardo Rodrigues <[email protected]>
Tested-by: M.Hanny Sabbagh <[email protected]>
Tested-by: Oussama BEN BRAHIM <[email protected]>
Tested-by: Ismael Ferreras Morezuelas <[email protected]>
Signed-off-by: Ismael Ferreras Morezuelas <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Rework the remaining setsockopt code to pass a sockptr_t instead of a
plain user pointer. This removes the last remaining set_fs(KERNEL_DS)
outside of architecture specific code.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Stefan Schmidt <[email protected]> [ieee802154]
Acked-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Just check for a NULL method instead of wiring up
sock_no_{get,set}sockopt.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Add functionality to disable and remove advertising instances,
and use that functionality in MGMT add/remove advertising calls.
Currently, advertising is globally-disabled, i.e. all instances are
disabled together, even if hardware offloading is available. This
patch adds functionality to disable and remove individual adv
instances, solving two issues:
1. On new advertisement registration, a global disable was done, and
then only the new instance was enabled. This meant only the newest
instance was actually enabled.
2. On advertisement removal, the structure was removed, but the instance
was never disabled or removed, which is incorrect with hardware offload
support.
Signed-off-by: Daniel Winkler <[email protected]>
Reviewed-by: Shyh-In Hwang <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Even with one advertisement monitor in place, the scan policy should use
the whitelist while the system is going to suspend to prevent waking by
random advertisement.
The following test was performed.
- With a paired device, register one advertisement monitor, suspend
the system and verify that the host was not awaken by random
advertisements.
Signed-off-by: Miao-chen Chou <[email protected]>
Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
This patch adds an le_simult_central_peripheral features which allows a
clients to determine if the controller is able to support peripheral and
central connections separately and at the same time.
Signed-off-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
This fixes the kernel oops by removing unnecessary background scan
update from hci_adv_monitors_clear() which shouldn't invoke any work
queue.
The following test was performed.
- Run "rmmod btusb" and verify that no kernel oops is triggered.
Signed-off-by: Miao-chen Chou <[email protected]>
Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
This patch fixes active scans to use the configured default parameters.
Signed-off-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When restarting LE scanning, check if it's currently paused before
enabling passive scanning.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When the extended advertisement feature is enabled, a hardcoded min and
max interval of 0x8000 is used. This patch fixes this issue by using
the configured min/max value.
This was validated by setting min/max in main.conf and making sure the
right setting is applied:
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen
25 #93 [hci0] 10.953011
…
Min advertising interval: 181.250 msec (0x0122)
Max advertising interval: 181.250 msec (0x0122)
…
Signed-off-by: Alain Michaud <[email protected]>
Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Daniel Winkler <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
The command status reply is only for failure. When completing set system
config command, the reply has to be command complete.
Signed-off-by: Marcel Holtmann <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
If user decides to cancel the ongoing pairing process (e.g. by clicking
the cancel button on pairing/passkey window), abort any ongoing pairing
and then terminate the link if it was created because of the pair
device action.
Signed-off-by: Manish Mandlik <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This calls hci_update_background_scan() when there is any update on the
advertisement monitors. If there is at least one advertisement monitor,
the filtering policy of scan parameters should be 0x00. This also reports
device found mgmt events if there is at least one monitor.
The following cases were tested with btmgmt advmon-* commands.
(1) add a ADV monitor and observe that the passive scanning is
triggered.
(2) remove the last ADV monitor and observe that the passive scanning is
terminated.
(3) with a LE peripheral paired, repeat (1) and observe the passive
scanning continues.
(4) with a LE peripheral paired, repeat (2) and observe the passive
scanning continues.
(5) with a ADV monitor, suspend/resume the host and observe the passive
scanning continues.
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This notifies management sockets on MGMT_EV_ADV_MONITOR_REMOVED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-remove command on one
console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other.
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This notifies management sockets on MGMT_EV_ADV_MONITOR_ADDED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-add command on one
console and observe a MGMT_EV_ADV_MONITOR_ADDED event on the other
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This adds the request handler of MGMT_OP_REMOVE_ADV_MONITOR command.
Note that the controller-based monitoring is not yet in place. This
removes the internal monitor(s) without sending HCI traffic, so the
request returns immediately.
The following test was performed.
- Issue btmgmt advmon-remove with valid and invalid handles.
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command.
Note that the controller-based monitoring is not yet in place. This tracks
the content of the monitor without sending HCI traffic, so the request
returns immediately.
The following manual test was performed.
- Issue btmgmt advmon-add with valid and invalid inputs.
- Issue btmgmt advmon-add more the allowed number of monitors.
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
command. Since the controller-based monitoring is not yet in place, this
report only the supported features but not the enabled features.
The following test was performed.
- Issuing btmgmt advmon-features.
Signed-off-by: Miao-chen Chou <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Replace the wakeable boolean with flags in hci_conn_params and all users
of this boolean. This will be used by the get/set device flags mgmt op.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Since the classic device list now supports flags, convert the wakeable
list into a flag on the existing device list.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
In order to more easily add device flags to classic devices, create
a new type of bdaddr_list that supports setting flags.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Alain Michaud <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Waiman Long