* [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
2026-05-20 13:50 [PATCH v2] " Michael Bommarito
@ 2026-05-21 0:05 ` Michael Bommarito
0 siblings, 0 replies; 6+ messages in thread
From: Michael Bommarito @ 2026-05-21 0:05 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-bluetooth, netdev, linux-kernel, stable
net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR
signaling packets up to the channel MTU and dispatches each command
without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer
within radio range can send a fixed-channel CID 0x0001 packet that is
larger than MTUsig and contains many L2CAP_ECHO_REQ commands before
pairing. In a real-radio stock-kernel run, one 681-byte signaling
packet containing 168 zero-length ECHO_REQ commands made the target
transmit 168 ECHO_RSP frames over about 220 ms.
Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can
force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling
packet containing packed ECHO_REQ commands.
Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and
reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP
carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.
The Bluetooth Core spec wording for MTUExceeded says the reject
identifier shall match the first request command in the packet, and
that packets containing only responses shall be silently discarded.
Linux intentionally deviates from that prescription: silently
discarding desynchronizes the peer because the remote stack never
learns its responses were dropped, and locating the first request
command requires walking command headers past MTUsig, i.e. processing
bytes from a packet we have already decided is too large to process.
We therefore always emit one reject and use the identifier from the
first command header (a single fixed-offset byte read), falling back
to zero when the packet is too short to carry a header at all.
The unrestricted BR/EDR signaling parser and ECHO_REQ response path both
trace to the initial git import; no later introducing commit is
available for a Fixes tag.
Cc: stable@vger.kernel.org
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
Assisted-by: Claude:claude-opus-4-7
Assisted-by: Codex:gpt-5-5-xhigh
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
I reproduced the stock behavior with a real-radio BR/EDR ACL link and a
harness that sends a single fixed-channel signaling packet containing
packed zero-length ECHO_REQ commands, and confirmed on a patched kernel
that the same packet now produces one L2CAP_REJ_MTU_EXCEEDED command
reject and zero ECHO_RSP frames. The patched code builds for
net/bluetooth/l2cap_core.o on x86_64 defconfig with W=1. There are no
in-tree Bluetooth selftests that reference l2cap_sig_channel(),
L2CAP_SIG_MTU, or L2CAP_ECHO_REQ.
Changes in v3:
- Drop l2cap_sig_cmd_is_req() and l2cap_sig_first_req_ident(); the
reject is now unconditional and uses only the first command
header's identifier byte at a fixed offset. Per Luiz, the spec's
"match the first request command identifier" rule would require
parsing past MTUsig, and the spec's "silently discard if only
responses" rule desynchronizes the peer.
- Replace the v2 walk with a verbose comment quoting the relevant
Bluetooth Core section and documenting why Linux deviates.
Changes in v2:
- Replace the per-PDU echo-count cap with the MTUsig direction from
review.
- Reject the whole over-MTUsig signaling packet with one
L2CAP_REJ_MTU_EXCEEDED command reject.
- Add L2CAP_SIG_MTU and drop over-MTUsig packets when no valid request
command identifier is found.
v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 47 +++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 5172afee54943..e0a1f2293679a 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -33,6 +33,7 @@
/* L2CAP defaults */
#define L2CAP_DEFAULT_MTU 672
#define L2CAP_DEFAULT_MIN_MTU 48
+#define L2CAP_SIG_MTU 48 /* BR/EDR signaling MTU */
#define L2CAP_DEFAULT_FLUSH_TO 0xFFFF
#define L2CAP_EFS_DEFAULT_FLUSH_TO 0xFFFFFFFF
#define L2CAP_DEFAULT_TX_WINDOW 63
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 7701528f11677..0b1e062057695 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5618,6 +5618,15 @@ static inline void l2cap_sig_send_rej(struct l2cap_conn *conn, u16 ident)
l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
}
+static inline void l2cap_sig_send_mtu_rej(struct l2cap_conn *conn, u8 ident)
+{
+ struct l2cap_cmd_rej_mtu rej;
+
+ rej.reason = cpu_to_le16(L2CAP_REJ_MTU_EXCEEDED);
+ rej.max_mtu = cpu_to_le16(L2CAP_SIG_MTU);
+ l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
+}
+
static inline void l2cap_sig_channel(struct l2cap_conn *conn,
struct sk_buff *skb)
{
@@ -5630,6 +5639,44 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
if (hcon->type != ACL_LINK)
goto drop;
+ /*
+ * Bluetooth Core v5.4, Vol 3, Part A, Section 4: the BR/EDR
+ * signaling channel has a fixed signaling MTU (MTUsig) whose
+ * minimum and default is 48 octets. Section 4.1 says that on
+ * an MTUExceeded command reject the identifier "shall match
+ * the first request command in the L2CAP packet" and that
+ * packets containing only response commands "shall be
+ * silently discarded".
+ *
+ * Linux intentionally deviates from that prescription:
+ *
+ * 1. Silently discarding desynchronizes the peer. The
+ * remote stack never learns its responses were dropped,
+ * so any state machine waiting on a paired response
+ * stalls until its own timer fires.
+ *
+ * 2. Locating "the first request command" requires walking
+ * command headers past MTUsig, i.e. processing bytes
+ * from a packet we have already decided is too large to
+ * process.
+ *
+ * Reject every over-MTUsig signaling packet with one
+ * L2CAP_REJ_MTU_EXCEEDED command reject. The reject's
+ * reason field is what tells the peer that the whole packet
+ * was discarded; the identifier value is informational, so
+ * we use the identifier from the first command header (a
+ * single fixed-offset byte read) or zero when the packet is
+ * too short to carry even one header.
+ */
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = (skb->len >= L2CAP_CMD_HDR_SIZE) ?
+ skb->data[1] : 0;
+
+ BT_DBG("signaling packet exceeds MTU");
+ l2cap_sig_send_mtu_rej(conn, ident);
+ goto drop;
+ }
+
while (skb->len >= L2CAP_CMD_HDR_SIZE) {
u16 len;
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
@ 2026-05-21 0:13 Michael Bommarito
2026-05-21 0:26 ` Jakub Kicinski
2026-05-21 4:27 ` [v3] " bluez.test.bot
0 siblings, 2 replies; 6+ messages in thread
From: Michael Bommarito @ 2026-05-21 0:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-bluetooth, netdev, linux-kernel, stable
net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR
signaling packets up to the channel MTU and dispatches each command
without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer
within radio range can send a fixed-channel CID 0x0001 packet that is
larger than MTUsig and contains many L2CAP_ECHO_REQ commands before
pairing. In a real-radio stock-kernel run, one 681-byte signaling
packet containing 168 zero-length ECHO_REQ commands made the target
transmit 168 ECHO_RSP frames over about 220 ms.
Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can
force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling
packet containing packed ECHO_REQ commands.
Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and
reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP
carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.
The Bluetooth Core spec wording for MTUExceeded says the reject
identifier shall match the first request command in the packet, and
that packets containing only responses shall be silently discarded.
Linux intentionally deviates from that prescription: silently
discarding desynchronizes the peer because the remote stack never
learns its responses were dropped, and locating the first request
command requires walking command headers past MTUsig, i.e. processing
bytes from a packet we have already decided is too large to process.
We therefore always emit one reject and use the identifier from the
first command header (a single fixed-offset byte read), falling back
to zero when the packet is too short to carry a header at all.
The unrestricted BR/EDR signaling parser and ECHO_REQ response path both
trace to the initial git import; no later introducing commit is
available for a Fixes tag.
Cc: stable@vger.kernel.org
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
Assisted-by: Claude:claude-opus-4-7
Assisted-by: Codex:gpt-5-5-xhigh
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Resending as top level message per netdev guidance.
I reproduced the stock behavior with a real-radio BR/EDR ACL link and a
harness that sends a single fixed-channel signaling packet containing
packed zero-length ECHO_REQ commands, and confirmed on a patched kernel
that the same packet now produces one L2CAP_REJ_MTU_EXCEEDED command
reject and zero ECHO_RSP frames. The patched code builds for
net/bluetooth/l2cap_core.o on x86_64 defconfig with W=1. There are no
in-tree Bluetooth selftests that reference l2cap_sig_channel(),
L2CAP_SIG_MTU, or L2CAP_ECHO_REQ.
Changes in v3:
- Drop l2cap_sig_cmd_is_req() and l2cap_sig_first_req_ident(); the
reject is now unconditional and uses only the first command
header's identifier byte at a fixed offset. Per Luiz, the spec's
"match the first request command identifier" rule would require
parsing past MTUsig, and the spec's "silently discard if only
responses" rule desynchronizes the peer.
- Replace the v2 walk with a verbose comment quoting the relevant
Bluetooth Core section and documenting why Linux deviates.
Changes in v2:
- Replace the per-PDU echo-count cap with the MTUsig direction from
review.
- Reject the whole over-MTUsig signaling packet with one
L2CAP_REJ_MTU_EXCEEDED command reject.
- Add L2CAP_SIG_MTU and drop over-MTUsig packets when no valid request
command identifier is found.
v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com
v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c | 47 +++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 5172afee54943..e0a1f2293679a 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -33,6 +33,7 @@
/* L2CAP defaults */
#define L2CAP_DEFAULT_MTU 672
#define L2CAP_DEFAULT_MIN_MTU 48
+#define L2CAP_SIG_MTU 48 /* BR/EDR signaling MTU */
#define L2CAP_DEFAULT_FLUSH_TO 0xFFFF
#define L2CAP_EFS_DEFAULT_FLUSH_TO 0xFFFFFFFF
#define L2CAP_DEFAULT_TX_WINDOW 63
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 7701528f11677..0b1e062057695 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5618,6 +5618,15 @@ static inline void l2cap_sig_send_rej(struct l2cap_conn *conn, u16 ident)
l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
}
+static inline void l2cap_sig_send_mtu_rej(struct l2cap_conn *conn, u8 ident)
+{
+ struct l2cap_cmd_rej_mtu rej;
+
+ rej.reason = cpu_to_le16(L2CAP_REJ_MTU_EXCEEDED);
+ rej.max_mtu = cpu_to_le16(L2CAP_SIG_MTU);
+ l2cap_send_cmd(conn, ident, L2CAP_COMMAND_REJ, sizeof(rej), &rej);
+}
+
static inline void l2cap_sig_channel(struct l2cap_conn *conn,
struct sk_buff *skb)
{
@@ -5630,6 +5639,44 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
if (hcon->type != ACL_LINK)
goto drop;
+ /*
+ * Bluetooth Core v5.4, Vol 3, Part A, Section 4: the BR/EDR
+ * signaling channel has a fixed signaling MTU (MTUsig) whose
+ * minimum and default is 48 octets. Section 4.1 says that on
+ * an MTUExceeded command reject the identifier "shall match
+ * the first request command in the L2CAP packet" and that
+ * packets containing only response commands "shall be
+ * silently discarded".
+ *
+ * Linux intentionally deviates from that prescription:
+ *
+ * 1. Silently discarding desynchronizes the peer. The
+ * remote stack never learns its responses were dropped,
+ * so any state machine waiting on a paired response
+ * stalls until its own timer fires.
+ *
+ * 2. Locating "the first request command" requires walking
+ * command headers past MTUsig, i.e. processing bytes
+ * from a packet we have already decided is too large to
+ * process.
+ *
+ * Reject every over-MTUsig signaling packet with one
+ * L2CAP_REJ_MTU_EXCEEDED command reject. The reject's
+ * reason field is what tells the peer that the whole packet
+ * was discarded; the identifier value is informational, so
+ * we use the identifier from the first command header (a
+ * single fixed-offset byte read) or zero when the packet is
+ * too short to carry even one header.
+ */
+ if (skb->len > L2CAP_SIG_MTU) {
+ u8 ident = (skb->len >= L2CAP_CMD_HDR_SIZE) ?
+ skb->data[1] : 0;
+
+ BT_DBG("signaling packet exceeds MTU");
+ l2cap_sig_send_mtu_rej(conn, ident);
+ goto drop;
+ }
+
while (skb->len >= L2CAP_CMD_HDR_SIZE) {
u16 len;
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
2026-05-21 0:13 [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig Michael Bommarito
@ 2026-05-21 0:26 ` Jakub Kicinski
2026-05-21 0:32 ` Michael Bommarito
2026-05-21 4:27 ` [v3] " bluez.test.bot
1 sibling, 1 reply; 6+ messages in thread
From: Jakub Kicinski @ 2026-05-21 0:26 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
On Wed, 20 May 2026 20:13:27 -0400 Michael Bommarito wrote:
> From: Michael Bommarito <michael.bommarito@gmail.com>
Please (tell your bot to) use the get_maintainer script.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
2026-05-21 0:26 ` Jakub Kicinski
@ 2026-05-21 0:32 ` Michael Bommarito
2026-05-21 0:42 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Michael Bommarito @ 2026-05-21 0:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
On Wed, May 20, 2026 at 8:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
> Please (tell your bot to) use the get_maintainer script.
It (and I) did, but I think this is because net/bluetooth/ matches net/, right?
Here's what I see when I run it. Is there a different set of args
that I should be using for netdev or net/bluetooth/ in particular?
Marcel Holtmann <marcel@holtmann.org> (maintainer:BLUETOOTH SUBSYSTEM)
Luiz Augusto von Dentz <luiz.dentz@gmail.com> (maintainer:BLUETOOTH SUBSYSTEM)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING [GENERAL])
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING [GENERAL])
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING [GENERAL])
Simon Horman <horms@kernel.org> (reviewer:NETWORKING [GENERAL])
linux-bluetooth@vger.kernel.org (open list:BLUETOOTH SUBSYSTEM)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-kernel@vger.kernel.org (open list)
Or did you mean because of Fixes:? This dates back to original git
import commit, so I thought the practice is to skip a Fixes: tag
Thanks,
Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
2026-05-21 0:32 ` Michael Bommarito
@ 2026-05-21 0:42 ` Jakub Kicinski
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Kicinski @ 2026-05-21 0:42 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-bluetooth, netdev,
linux-kernel, stable
On Wed, 20 May 2026 20:32:28 -0400 Michael Bommarito wrote:
> On Wed, May 20, 2026 at 8:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > Please (tell your bot to) use the get_maintainer script.
>
> It (and I) did, but I think this is because net/bluetooth/ matches net/, right?
Looks like we're missing an X, sorry.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
2026-05-21 0:13 [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig Michael Bommarito
2026-05-21 0:26 ` Jakub Kicinski
@ 2026-05-21 4:27 ` bluez.test.bot
1 sibling, 0 replies; 6+ messages in thread
From: bluez.test.bot @ 2026-05-21 4:27 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1098364
---Test result---
Test Summary:
CheckPatch FAIL 1.00 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.25 seconds
CheckAllWarning PASS 28.83 seconds
CheckSparse PASS 27.41 seconds
BuildKernel32 PASS 25.53 seconds
TestRunnerSetup PASS 526.88 seconds
TestRunner_l2cap-tester PASS 376.33 seconds
IncrementalBuild PASS 24.88 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?
total: 0 errors, 1 warnings, 0 checks, 66 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14585530.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
38: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
39: B1 Line exceeds max length (84>80): "Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
73: B1 Line exceeds max length (82>80): "v1: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com"
74: B1 Line exceeds max length (82>80): "v2: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com"
https://github.com/bluez/bluetooth-next/pull/225
---
Regards,
Linux Bluetooth
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-05-21 4:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-21 0:13 [PATCH v3] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig Michael Bommarito
2026-05-21 0:26 ` Jakub Kicinski
2026-05-21 0:32 ` Michael Bommarito
2026-05-21 0:42 ` Jakub Kicinski
2026-05-21 4:27 ` [v3] " bluez.test.bot
-- strict thread matches above, loose matches on Subject: below --
2026-05-20 13:50 [PATCH v2] " Michael Bommarito
2026-05-21 0:05 ` [PATCH v3] " Michael Bommarito
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox