| Message ID | 20231209105518.GA408904@v4bel-B760M-AORUS-ELITE-AX |
|---|---|
| State | Accepted |
| Commit | 63b55655d30b119157432aa545989a2fb73c378e |
| Headers | show |
| Series | [v2] Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg | expand |
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=808455 ---Test result--- Test Summary: CheckPatch PASS 0.65 seconds GitLint PASS 1.39 seconds SubjectPrefix PASS 0.63 seconds BuildKernel PASS 26.92 seconds CheckAllWarning PASS 30.69 seconds CheckSparse WARNING 35.03 seconds CheckSmatch PASS 98.43 seconds BuildKernel32 PASS 26.94 seconds TestRunnerSetup PASS 429.62 seconds TestRunner_l2cap-tester PASS 23.37 seconds TestRunner_iso-tester PASS 45.83 seconds TestRunner_bnep-tester PASS 6.95 seconds TestRunner_mgmt-tester PASS 162.57 seconds TestRunner_rfcomm-tester PASS 10.76 seconds TestRunner_sco-tester PASS 14.44 seconds TestRunner_ioctl-tester PASS 11.75 seconds TestRunner_mesh-tester PASS 8.64 seconds TestRunner_smp-tester PASS 9.63 seconds TestRunner_userchan-tester PASS 7.28 seconds IncrementalBuild PASS 25.21 seconds Details ############################## Test: CheckSparse - WARNING Desc: Run sparse tool with linux kernel Output: net/bluetooth/af_bluetooth.c:223:25: warning: context imbalance in 'bt_accept_enqueue' - different lock contexts for basic block --- Regards, Linux Bluetooth
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Sat, 9 Dec 2023 05:55:18 -0500 you wrote: > This can cause a race with bt_sock_ioctl() because > bt_sock_recvmsg() gets the skb from sk->sk_receive_queue > and then frees it without holding lock_sock. > A use-after-free for a skb occurs with the following flow. > ``` > bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram() > bt_sock_ioctl() -> skb_peek() > ``` > Add lock_sock to bt_sock_recvmsg() to fix this issue. > > [...] Here is the summary with links: - [v2] Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg https://git.kernel.org/bluetooth/bluetooth-next/c/63b55655d30b You are awesome, thank you!
Hi Hyunwoo, I've been looking into a few CVEs, the one of interest in this case is CVE-2024-21803. There seems to be little publicly available information about this CVE, however the title of this patch and the affected kernel range suggest this may be a fix for this CVE. Would you be able to clarify whether this is a fix for CVE-2024-21803? Thanks, Martyn On 09/12/2023 10:55, Hyunwoo Kim wrote: > This can cause a race with bt_sock_ioctl() because > bt_sock_recvmsg() gets the skb from sk->sk_receive_queue > and then frees it without holding lock_sock. > A use-after-free for a skb occurs with the following flow. > ``` > bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram() > bt_sock_ioctl() -> skb_peek() > ``` > Add lock_sock to bt_sock_recvmsg() to fix this issue. > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Signed-off-by: Hyunwoo Kim <v4bel@theori.io> > --- > v1 -> v2: Remove duplicate release_sock()s > --- > net/bluetooth/af_bluetooth.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c > index 336a76165454..b93464ac3517 100644 > --- a/net/bluetooth/af_bluetooth.c > +++ b/net/bluetooth/af_bluetooth.c > @@ -309,11 +309,14 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, > if (flags & MSG_OOB) > return -EOPNOTSUPP; > > + lock_sock(sk); > + > skb = skb_recv_datagram(sk, flags, &err); > if (!skb) { > if (sk->sk_shutdown & RCV_SHUTDOWN) > - return 0; > + err = 0; > > + release_sock(sk); > return err; > } > > @@ -343,6 +346,8 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, > > skb_free_datagram(sk, skb); > > + release_sock(sk); > + > if (flags & MSG_TRUNC) > copied = skblen; >
Dear Martyn Welch, I apologize for the long delay in responding. On Thu, Feb 22, 2024 at 11:23:05AM +0000, Martyn Welch wrote: > Hi Hyunwoo, > > I've been looking into a few CVEs, the one of interest in this case is > CVE-2024-21803. > > There seems to be little publicly available information about this CVE, > however the title of this patch and the affected kernel range suggest this > may be a fix for this CVE. This patch is for CVE-2023-51779. > > Would you be able to clarify whether this is a fix for CVE-2024-21803? IMO, CVE-2024-21803 appears to be the same vulnerability as CVE-2023-51779. It appears to be a duplicate CVE that was registered due to an unknown reporter's mistake. Best Regards, Hyunwoo Kim > > Thanks, > > Martyn > > On 09/12/2023 10:55, Hyunwoo Kim wrote: > > This can cause a race with bt_sock_ioctl() because > > bt_sock_recvmsg() gets the skb from sk->sk_receive_queue > > and then frees it without holding lock_sock. > > A use-after-free for a skb occurs with the following flow. > > ``` > > bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram() > > bt_sock_ioctl() -> skb_peek() > > ``` > > Add lock_sock to bt_sock_recvmsg() to fix this issue. > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > > Signed-off-by: Hyunwoo Kim <v4bel@theori.io> > > --- > > v1 -> v2: Remove duplicate release_sock()s > > --- > > net/bluetooth/af_bluetooth.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c > > index 336a76165454..b93464ac3517 100644 > > --- a/net/bluetooth/af_bluetooth.c > > +++ b/net/bluetooth/af_bluetooth.c > > @@ -309,11 +309,14 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, > > if (flags & MSG_OOB) > > return -EOPNOTSUPP; > > + lock_sock(sk); > > + > > skb = skb_recv_datagram(sk, flags, &err); > > if (!skb) { > > if (sk->sk_shutdown & RCV_SHUTDOWN) > > - return 0; > > + err = 0; > > + release_sock(sk); > > return err; > > } > > @@ -343,6 +346,8 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, > > skb_free_datagram(sk, skb); > > + release_sock(sk); > > + > > if (flags & MSG_TRUNC) > > copied = skblen;
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index 336a76165454..b93464ac3517 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -309,11 +309,14 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; + lock_sock(sk); + skb = skb_recv_datagram(sk, flags, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) - return 0; + err = 0; + release_sock(sk); return err; } @@ -343,6 +346,8 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, skb_free_datagram(sk, skb); + release_sock(sk); + if (flags & MSG_TRUNC) copied = skblen;
This can cause a race with bt_sock_ioctl() because bt_sock_recvmsg() gets the skb from sk->sk_receive_queue and then frees it without holding lock_sock. A use-after-free for a skb occurs with the following flow. ``` bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram() bt_sock_ioctl() -> skb_peek() ``` Add lock_sock to bt_sock_recvmsg() to fix this issue. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim <v4bel@theori.io> --- v1 -> v2: Remove duplicate release_sock()s --- net/bluetooth/af_bluetooth.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)