net/bluetooth/hci_sock.c | 26 +++++++++++-------- net/bluetooth/iso.c | 27 ++++++++++---------- net/bluetooth/l2cap_sock.c | 61 +++++++++++++++++++++++++++------------------ net/bluetooth/rfcomm/sock.c | 30 ++++++++++++---------- net/bluetooth/sco.c | 59 ++++++++++++++++++++++--------------------- 5 files changed, 114 insertions(+), 89 deletions(-)
Continue the conversion to .getsockopt_iter for the Bluetooth socket
families: hci_sock, ISO, RFCOMM, SCO and L2CAP. The first patch is a
small precursor that fixes a long-standing 1-byte put_user write in
hci_sock_getsockopt_old() so the subsequent conversion stays mechanical.
The riskiest change in this series is the SCO BT_CODEC conversion: it
is the only one that drops an open-coded ptr cursor in favour of
relying on iter_out advancing naturally on every copy_to_iter() call.
Every other socket option is a near-mechanical s/copy_to_user/
copy_to_iter/ rewrite, but BT_CODEC walks a variable-length list of
codecs + capabilities and previously tracked its own write offset by
hand. Getting the cursor semantics wrong here would silently truncate
or misalign user-visible codec data.
For more context about the motivation for this change, please check
commit 67fab22a7ad ("net: add getsockopt_iter callback to proto_ops")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- rebase the tree on top of bluetooth-next.
- Remove the selftest, which was mixing network and bluetooth together.
- Link to v1: https://patch.msgid.link/20260511-getsock_three-v1-0-1461fa8786ab@debian.org
To: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Breno Leitao (6):
Bluetooth: hci_sock: write the full optval for getsockopt
Bluetooth: hci_sock: convert to getsockopt_iter
Bluetooth: ISO: convert to getsockopt_iter
Bluetooth: RFCOMM: convert to getsockopt_iter
Bluetooth: L2CAP: convert to getsockopt_iter
Bluetooth: SCO: convert to getsockopt_iter
net/bluetooth/hci_sock.c | 26 +++++++++++--------
net/bluetooth/iso.c | 27 ++++++++++----------
net/bluetooth/l2cap_sock.c | 61 +++++++++++++++++++++++++++------------------
net/bluetooth/rfcomm/sock.c | 30 ++++++++++++----------
net/bluetooth/sco.c | 59 ++++++++++++++++++++++---------------------
5 files changed, 114 insertions(+), 89 deletions(-)
---
base-commit: c2f0079e8c42fd6814c8d6b1491e3ce0a0e3b3fa
change-id: 20260511-getsock_three-d0d7f1b2629e
Best regards,
--
Breno Leitao <leitao@debian.org>
Hi Breno,
On Tue, May 12, 2026 at 7:12 AM Breno Leitao <leitao@debian.org> wrote:
>
> Continue the conversion to .getsockopt_iter for the Bluetooth socket
> families: hci_sock, ISO, RFCOMM, SCO and L2CAP. The first patch is a
> small precursor that fixes a long-standing 1-byte put_user write in
> hci_sock_getsockopt_old() so the subsequent conversion stays mechanical.
>
> The riskiest change in this series is the SCO BT_CODEC conversion: it
> is the only one that drops an open-coded ptr cursor in favour of
> relying on iter_out advancing naturally on every copy_to_iter() call.
> Every other socket option is a near-mechanical s/copy_to_user/
> copy_to_iter/ rewrite, but BT_CODEC walks a variable-length list of
> codecs + capabilities and previously tracked its own write offset by
> hand. Getting the cursor semantics wrong here would silently truncate
> or misalign user-visible codec data.
>
> For more context about the motivation for this change, please check
> commit 67fab22a7ad ("net: add getsockopt_iter callback to proto_ops")
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - rebase the tree on top of bluetooth-next.
> - Remove the selftest, which was mixing network and bluetooth together.
> - Link to v1: https://patch.msgid.link/20260511-getsock_three-v1-0-1461fa8786ab@debian.org
>
> To: Marcel Holtmann <marcel@holtmann.org>
> To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> Breno Leitao (6):
> Bluetooth: hci_sock: write the full optval for getsockopt
> Bluetooth: hci_sock: convert to getsockopt_iter
> Bluetooth: ISO: convert to getsockopt_iter
> Bluetooth: RFCOMM: convert to getsockopt_iter
> Bluetooth: L2CAP: convert to getsockopt_iter
> Bluetooth: SCO: convert to getsockopt_iter
>
> net/bluetooth/hci_sock.c | 26 +++++++++++--------
> net/bluetooth/iso.c | 27 ++++++++++----------
> net/bluetooth/l2cap_sock.c | 61 +++++++++++++++++++++++++++------------------
> net/bluetooth/rfcomm/sock.c | 30 ++++++++++++----------
> net/bluetooth/sco.c | 59 ++++++++++++++++++++++---------------------
> 5 files changed, 114 insertions(+), 89 deletions(-)
> ---
> base-commit: c2f0079e8c42fd6814c8d6b1491e3ce0a0e3b3fa
> change-id: 20260511-getsock_three-d0d7f1b2629e
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
There are some comments from sashiko on this:
https://sashiko.dev/#/patchset/20260512-getsock_three-v2-0-30b7b22ef14c%40debian.org
Now Im not sure the truncating is actually used by our tools, but that
sounds like it could break userspace if we don't check properly, or
have you already done this for other socket families and it was
considered to be ok?
--
Luiz Augusto von Dentz
Hello Luiz,
On Thu, May 14, 2026 at 01:51:16PM -0400, Luiz Augusto von Dentz wrote:
> On Tue, May 12, 2026 at 7:12 AM Breno Leitao <leitao@debian.org> wrote:
> >
> > Continue the conversion to .getsockopt_iter for the Bluetooth socket
> > families: hci_sock, ISO, RFCOMM, SCO and L2CAP. The first patch is a
> > small precursor that fixes a long-standing 1-byte put_user write in
> > hci_sock_getsockopt_old() so the subsequent conversion stays mechanical.
> >
> > The riskiest change in this series is the SCO BT_CODEC conversion: it
> > is the only one that drops an open-coded ptr cursor in favour of
> > relying on iter_out advancing naturally on every copy_to_iter() call.
> > Every other socket option is a near-mechanical s/copy_to_user/
> > copy_to_iter/ rewrite, but BT_CODEC walks a variable-length list of
> > codecs + capabilities and previously tracked its own write offset by
> > hand. Getting the cursor semantics wrong here would silently truncate
> > or misalign user-visible codec data.
> >
> > For more context about the motivation for this change, please check
> > commit 67fab22a7ad ("net: add getsockopt_iter callback to proto_ops")
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > Changes in v2:
> > - rebase the tree on top of bluetooth-next.
> > - Remove the selftest, which was mixing network and bluetooth together.
> > - Link to v1: https://patch.msgid.link/20260511-getsock_three-v1-0-1461fa8786ab@debian.org
> >
> > To: Marcel Holtmann <marcel@holtmann.org>
> > To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> > Cc: linux-bluetooth@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > ---
> > Breno Leitao (6):
> > Bluetooth: hci_sock: write the full optval for getsockopt
> > Bluetooth: hci_sock: convert to getsockopt_iter
> > Bluetooth: ISO: convert to getsockopt_iter
> > Bluetooth: RFCOMM: convert to getsockopt_iter
> > Bluetooth: L2CAP: convert to getsockopt_iter
> > Bluetooth: SCO: convert to getsockopt_iter
> >
> > net/bluetooth/hci_sock.c | 26 +++++++++++--------
> > net/bluetooth/iso.c | 27 ++++++++++----------
> > net/bluetooth/l2cap_sock.c | 61 +++++++++++++++++++++++++++------------------
> > net/bluetooth/rfcomm/sock.c | 30 ++++++++++++----------
> > net/bluetooth/sco.c | 59 ++++++++++++++++++++++---------------------
> > 5 files changed, 114 insertions(+), 89 deletions(-)
> > ---
> > base-commit: c2f0079e8c42fd6814c8d6b1491e3ce0a0e3b3fa
> > change-id: 20260511-getsock_three-d0d7f1b2629e
> >
> > Best regards,
> > --
> > Breno Leitao <leitao@debian.org>
>
> There are some comments from sashiko on this:
>
> https://sashiko.dev/#/patchset/20260512-getsock_three-v2-0-30b7b22ef14c%40debian.org
>
> Now Im not sure the truncating is actually used by our tools, but that
> sounds like it could break userspace if we don't check properly, or
> have you already done this for other socket families and it was
> considered to be ok?
You're right — to clarify, the patch changes behavior when the user
provides a short optlen, preventing the overflow that existed before:
- Old code: put_user(opt, (u32 __user *)optval) unconditionally
writes sizeof(*ptr) bytes regardless of optlen, so optlen < 4
would overflow the user buffer and return 0.
- New code: copy_to_iter() respects the optlen boundary, eliminating
the overflow — but now a short buffer fails the strict length check
and returns -EFAULT instead of 0.
I don't believe any legitimate userspace relies on the old overflow
behavior, though there's a theoretical risk of breakage. I'm not deeply
familiar with the Bluetooth ecosystem specifically, but, I would prefer to
avoid the buffer overflow in such case.
I've addressed a similar issue in another subsystem recently:
https://lore.kernel.org/all/20260521-fix_llc-v2-1-ab44cc09179c@debian.org/
Anyway, let me know if you need me to change it.
--breno
© 2016 - 2026 Red Hat, Inc.