From: Sungwoo Kim iam@sung-woo.kim
[ Upstream commit bcd70260ef56e0aee8a4fc6cd214a419900b0765 ]
By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP
Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...)
ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106
invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............
ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561
invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....
ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390
invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......
ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932
invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828
ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753
invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
Signed-off-by: Sungwoo Kim iam@sung-woo.kim Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- net/bluetooth/l2cap_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 5e7fb30b2320..cbf0a9d5aabc 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -4183,7 +4183,8 @@ static inline int l2cap_config_req(struct l2cap_conn *conn,
chan->ident = cmd->ident; l2cap_send_cmd(conn, cmd->ident, L2CAP_CONF_RSP, len, rsp); - chan->num_conf_rsp++; + if (chan->num_conf_rsp < L2CAP_CONF_MAX_CONF_RSP) + chan->num_conf_rsp++;
/* Reset config buffer. */ chan->conf_len = 0;
From: Rasmus Villemoes linux@rasmusvillemoes.dk
[ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ]
When the name_assign_type attribute was introduced (commit 685343fc3ba6, "net: add name_assign_type netdev attribute"), the loopback device was explicitly mentioned as one which would make use of NET_NAME_PREDICTABLE:
The name_assign_type attribute gives hints where the interface name of a given net-device comes from. These values are currently defined: ... NET_NAME_PREDICTABLE: The ifname has been assigned by the kernel in a predictable way that is guaranteed to avoid reuse and always be the same for a given device. Examples include statically created devices like the loopback device [...]
Switch to that so that reading /sys/class/net/lo/name_assign_type produces something sensible instead of returning -EINVAL.
Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk Reviewed-by: Jacob Keller jacob.e.keller@intel.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/net/loopback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c index 1b65f0f975cf..f04f9a87840e 100644 --- a/drivers/net/loopback.c +++ b/drivers/net/loopback.c @@ -194,7 +194,7 @@ static __net_init int loopback_net_init(struct net *net) int err;
err = -ENOMEM; - dev = alloc_netdev(0, "lo", NET_NAME_UNKNOWN, loopback_setup); + dev = alloc_netdev(0, "lo", NET_NAME_PREDICTABLE, loopback_setup); if (!dev) goto out;
Hi!
From: Rasmus Villemoes linux@rasmusvillemoes.dk
[ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ]
When the name_assign_type attribute was introduced (commit 685343fc3ba6, "net: add name_assign_type netdev attribute"), the loopback device was explicitly mentioned as one which would make use of NET_NAME_PREDICTABLE:
The name_assign_type attribute gives hints where the interface name of a given net-device comes from. These values are currently defined:... NET_NAME_PREDICTABLE: The ifname has been assigned by the kernel in a predictable way that is guaranteed to avoid reuse and always be the same for a given device. Examples include statically created devices like the loopback device [...]
Switch to that so that reading /sys/class/net/lo/name_assign_type produces something sensible instead of returning -EINVAL.
This was already part of the previous autosel:
Date: Tue, 6 Dec 2022 04:51:42 -0500 From: Sasha Levin sashal@kernel.org Subject: [PATCH AUTOSEL 4.9 3/3] net: loopback: use NET_NAME_PREDICTABLE for name_assign_type X-Mailer: git-send-email 2.35.1
From: Rasmus Villemoes linux@rasmusvillemoes.dk
[ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ]
Best regards,
Pavel
On 15/12/2022 11.59, Pavel Machek wrote:
Hi!
From: Rasmus Villemoes linux@rasmusvillemoes.dk
[ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ]
When the name_assign_type attribute was introduced (commit 685343fc3ba6, "net: add name_assign_type netdev attribute"), the loopback device was explicitly mentioned as one which would make use of NET_NAME_PREDICTABLE:
The name_assign_type attribute gives hints where the interface name of a given net-device comes from. These values are currently defined:... NET_NAME_PREDICTABLE: The ifname has been assigned by the kernel in a predictable way that is guaranteed to avoid reuse and always be the same for a given device. Examples include statically created devices like the loopback device [...]
Switch to that so that reading /sys/class/net/lo/name_assign_type produces something sensible instead of returning -EINVAL.
This was already part of the previous autosel:
Yup, but it was punted for a week:
linux-stable-mirror@lists.linaro.org
-
Pavel Machek -
Rasmus Villemoes -
Sasha Levin