-
Notifications
You must be signed in to change notification settings - Fork 1
[PW_SID:1040193] Bluetooth: Perform careful capability checks in hci_sock_bind() #3258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: workflow
Are you sure you want to change the base?
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Previously, the HCI_SOCK_TRUSTED flag was set in hci_sock_bind() by checking capable(CAP_NET_ADMIN). This function verifies that the current caller of the bind system call has the required capability. However, this approach is vulnerable to a "confused deputy" attack. A malicious unprivileged program can open an HCI socket and deliberately share it with a privileged task (e.g., via file descriptor passing). If the privileged task is tricked into calling bind() on that socket, the capable() check will pass, and the socket will be marked as trusted. The original unprivileged program then retains access to this now-trusted socket, allowing it to perform privileged operations. This issue mirrors the vulnerability previously identified and fixed in hci_sock_ioctl(). Fix this by using sk_capable() instead of capable(). This ensures that both the task performing the bind and the socket opener must have the CAP_NET_ADMIN capability before the socket is granted the HCI_SOCK_TRUSTED status. Fixes: f4cdbb3 ("Bluetooth: Handle HCI raw socket transition from unbound to bound") Signed-off-by: Jerry Wu <w.7erry@foxmail.com>
|
CheckPatch |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
IncrementalBuild |
e7984f7 to
e352d45
Compare
Previously, the HCI_SOCK_TRUSTED flag was set in hci_sock_bind() by
checking capable(CAP_NET_ADMIN). This function verifies that the
current caller of the bind system call has the required capability.
However, this approach is vulnerable to a "confused deputy" attack. A
malicious unprivileged program can open an HCI socket and deliberately
share it with a privileged task (e.g., via file descriptor passing).
If the privileged task is tricked into calling bind() on that socket,
the capable() check will pass, and the socket will be marked as
trusted. The original unprivileged program then retains access to this
now-trusted socket, allowing it to perform privileged operations.
This issue mirrors the vulnerability previously identified and fixed
in hci_sock_ioctl().
Fix this by using sk_capable() instead of capable(). This ensures that
both the task performing the bind and the socket opener must have the
CAP_NET_ADMIN capability before the socket is granted the
HCI_SOCK_TRUSTED status.
Fixes: f4cdbb3 ("Bluetooth: Handle HCI raw socket transition from unbound to bound")
Signed-off-by: Jerry Wu w.7erry@foxmail.com
Commit 25c150a ("bluetooth: Perform careful capability checks in hci_sock_ioctl()")
fixed CVE-2023-2002. hci_sock_bind contains a similar logic. Would it make sense to
fix it in the same way?
Thank you for spending time reading this. Apologies if I missed anything.
net/bluetooth/hci_sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)