Hi Breno, 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? -- Luiz Augusto von Dentz
