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 <[email protected]> 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 <[email protected]> > > --- > > 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/[email protected] > > > > To: Marcel Holtmann <[email protected]> > > To: Luiz Augusto von Dentz <[email protected]> > > Cc: [email protected] > > Cc: [email protected] > > > > --- > > 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 <[email protected]> > > 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/[email protected]/ Anyway, let me know if you need me to change it. --breno
