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 <[email protected]>
---
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;
--
2.25.1
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 <[email protected]>:
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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
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 <[email protected]>
> ---
> 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 <[email protected]>
> > ---
> > 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;