* New CVE entries in this week
@ 2021-11-25 2:41 Masami Ichikawa
2021-11-25 9:14 ` [cip-dev] " Pavel Machek
[not found] ` <16BABF37827ACD8B.14741@lists.cip-project.org>
0 siblings, 2 replies; 6+ messages in thread
From: Masami Ichikawa @ 2021-11-25 2:41 UTC (permalink / raw)
To: cip-dev
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
Hi !
It's this week's CVE report.
This week reported two new CVEs.
* New CVEs
CVE-2021-33098: Improper input validation in the Intel(R) Ethernet ixgbe
driver for Linux before version 3.17.3 may allow an authenticated user to
potentially enable denial of service via local access.
CVSS v3 score is 5.5 MEDIUM.
Intel released fixed version of driver kit. Not sure this CVE affects
mainline's source code.
Fixed status
Intel released fixed version of driver kit.
CVE-2021-4001: bpf: Fix toctou on read-only map''s constant scalar tracking
CVSS v3 score is not provided.
This bug was introduced in 5.5-rc1 and fixed in 5.16-rc2. Patch for 5.15
is in stable-rt tree. Patch for 5.4(
https://lore.kernel.org/stable/163757721744154@kroah.com/) and 5.10(
https://lore.kernel.org/stable/1637577215186161@kroah.com/) are failed to
apply. However, this bug was introduced in 5.5-rc1 so 5.4 can be ignored?
Fixed status
mainline: [353050be4c19e102178ccc05988101887c25ae53]
* Updated CVEs
CVE-2021-3640: UAF in sco_send_frame function
5.10 and 5.15 are fixed this week.
Fixed status
mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951]
stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de]
stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896]
stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697]
stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab]
CVE-2021-43975: atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait
The mainline kernel was fixed in 5.16-rc2.
Fixed status
mainline: [b922f622592af76b57cbc566eaeccda0b31a3496]
Currently tracking CVEs
CVE-2021-31615: Unencrypted Bluetooth Low Energy baseband links in
Bluetooth Core Specifications 4.0 through 5.2
There is no fix information.
CVE-2020-26555: BR/EDR pin code pairing broken
No fix information
CVE-2020-26556: kernel: malleable commitment Bluetooth Mesh Provisioning
No fix information.
CVE-2020-26557: kernel: predictable Authvalue in Bluetooth Mesh
Provisioning Leads to MITM
No fix information.
CVE-2020-26559: kernel: Authvalue leak in Bluetooth Mesh Provisioning
No fix information.
CVE-2020-26560: kernel: impersonation attack in Bluetooth Mesh Provisioning
No fix information.
Regards,
--
Masami Ichikawa
Cybertrust Japan Co., Ltd.
Email :masami.ichikawa@cybertrust.co.jp
:masami.ichikawa@miraclelinux.com
[-- Attachment #2: Type: text/html, Size: 2907 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [cip-dev] New CVE entries in this week 2021-11-25 2:41 New CVE entries in this week Masami Ichikawa @ 2021-11-25 9:14 ` Pavel Machek [not found] ` <16BABF37827ACD8B.14741@lists.cip-project.org> 1 sibling, 0 replies; 6+ messages in thread From: Pavel Machek @ 2021-11-25 9:14 UTC (permalink / raw) To: cip-dev [-- Attachment #1: Type: text/plain, Size: 1278 bytes --] Hi! > * Updated CVEs > > CVE-2021-3640: UAF in sco_send_frame function > > 5.10 and 5.15 are fixed this week. > > Fixed status > > mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] Interesting. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 Author: Takashi Iwai <tiwai@suse.de> Says: This should be the last piece for fixing CVE-2021-3640 after a few already queued fixes. Which means more than 99c23da0eed is needed to fix this one, unfortunately it does not give us good way to identify what commits are needed. > CVE-2021-43975: atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait > > The mainline kernel was fixed in 5.16-rc2. > > Fixed status > > mainline: [b922f622592af76b57cbc566eaeccda0b31a3496] This is protection of kernel against malicious hardware. I believe we can ignore this. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <16BABF37827ACD8B.14741@lists.cip-project.org>]
* CVE-2021-3640: UAF in sco_send_frame function was Re: [cip-dev] New CVE entries in this week [not found] ` <16BABF37827ACD8B.14741@lists.cip-project.org> @ 2021-11-25 9:53 ` Pavel Machek 2021-11-25 14:22 ` Masami Ichikawa 0 siblings, 1 reply; 6+ messages in thread From: Pavel Machek @ 2021-11-25 9:53 UTC (permalink / raw) To: cip-dev [-- Attachment #1: Type: text/plain, Size: 3502 bytes --] Hi! > > CVE-2021-3640: UAF in sco_send_frame function > > > > 5.10 and 5.15 are fixed this week. > > > > Fixed status > > > > mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > > stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] > > Interesting. > > commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 > Author: Takashi Iwai <tiwai@suse.de> > > Says: > > This should be the last piece for fixing CVE-2021-3640 after a few > already queued fixes. > > Which means more than 99c23da0eed is needed to fix this one, > unfortunately it does not give us good way to identify what commits > are needed. Aha, but we have required information in cip-kernel-sec/issues/CVE-2021-3640.yml. It lists patches that should be fixing this. Some searching in the trees reveals that one of those patches is buggy itself, and additionaly 49d8a5606428ca0962d09050a5af81461ff90fbb is needed. The patches fixing this are: ~ stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, c20d8c197454068da758a83e09d93683f520d681, a1073aad497d0d071a71f61b721966a176d50c08] But we still miss backport of 27c24fda62b6 ("Bluetooth: switch to lock_sock in SCO") to 5.10, which has its own prerequisites according to the changelog. AFAICT those prerequisites are 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab and ba316be1b6a00db7126ed9a39f9bee434a508043, and both are in 5.10. I'm not sure how to express this in yml cleanly. I came with this: diff --git a/issues/CVE-2021-3640.yml b/issues/CVE-2021-3640.yml index fb52d5a..d386093 100644 --- a/issues/CVE-2021-3640.yml +++ b/issues/CVE-2021-3640.yml @@ -23,9 +23,23 @@ comments: there is no fixed information as of 2021/07/26. Fixed in bluetooth-next tree. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951. ubuntu/sbeattie: Possibly addressed by Desmond Cheong Zhi Xi's patchset. + pavel: We are one patch away from fixing this 5.10, 27c24fda62b6 is needed. fixed-by: - mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] - stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] + mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951, + e04480920d1eec9c061841399aa6f35b6f987d8b, + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, + 49d8a5606428ca0962d09050a5af81461ff90fbb, + ba316be1b6a00db7126ed9a39f9bee434a508043, + 27c24fda62b601d6f9ca5e992502578c4310876f, + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, + ba316be1b6a00db7126ed9a39f9bee434a508043] + stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, + f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, + c20d8c197454068da758a83e09d93683f520d681, + a1073aad497d0d071a71f61b721966a176d50c08, + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, + a1073aad497d0d071a71f61b721966a176d50c08] stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: CVE-2021-3640: UAF in sco_send_frame function was Re: [cip-dev] New CVE entries in this week 2021-11-25 9:53 ` CVE-2021-3640: UAF in sco_send_frame function was " Pavel Machek @ 2021-11-25 14:22 ` Masami Ichikawa 2021-11-26 10:02 ` Pavel Machek 0 siblings, 1 reply; 6+ messages in thread From: Masami Ichikawa @ 2021-11-25 14:22 UTC (permalink / raw) To: cip-dev Hi ! On Thu, Nov 25, 2021 at 6:53 PM Pavel Machek <pavel@denx.de> wrote: > > Hi! > > > > CVE-2021-3640: UAF in sco_send_frame function > > > > > > 5.10 and 5.15 are fixed this week. > > > > > > Fixed status > > > > > > mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > > > stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > > > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > > > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > > > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] > > > > Interesting. > > > > commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 > > Author: Takashi Iwai <tiwai@suse.de> > > > > Says: > > > > This should be the last piece for fixing CVE-2021-3640 after a few > > already queued fixes. > > > > Which means more than 99c23da0eed is needed to fix this one, > > unfortunately it does not give us good way to identify what commits > > are needed. > > Aha, but we have required information in > cip-kernel-sec/issues/CVE-2021-3640.yml. It lists patches that should > be fixing this. > > Some searching in the trees reveals that one of those patches is buggy > itself, and additionaly 49d8a5606428ca0962d09050a5af81461ff90fbb is > needed. > > The patches fixing this are: > > ~ stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > c20d8c197454068da758a83e09d93683f520d681, > a1073aad497d0d071a71f61b721966a176d50c08] > > But we still miss backport of 27c24fda62b6 ("Bluetooth: switch to > lock_sock in SCO") to 5.10, which has its own prerequisites > according to the changelog. AFAICT those prerequisites are > 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab and > ba316be1b6a00db7126ed9a39f9bee434a508043, and both are in 5.10. > > I'm not sure how to express this in yml cleanly. I came with this: > > diff --git a/issues/CVE-2021-3640.yml b/issues/CVE-2021-3640.yml > index fb52d5a..d386093 100644 > --- a/issues/CVE-2021-3640.yml > +++ b/issues/CVE-2021-3640.yml > @@ -23,9 +23,23 @@ comments: > there is no fixed information as of 2021/07/26. > Fixed in bluetooth-next tree. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951. > ubuntu/sbeattie: Possibly addressed by Desmond Cheong Zhi Xi's patchset. > + pavel: We are one patch away from fixing this 5.10, 27c24fda62b6 is needed. > fixed-by: > - mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > - stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > + mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951, > + e04480920d1eec9c061841399aa6f35b6f987d8b, > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > + 49d8a5606428ca0962d09050a5af81461ff90fbb, > + ba316be1b6a00db7126ed9a39f9bee434a508043, > + 27c24fda62b601d6f9ca5e992502578c4310876f, > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > + ba316be1b6a00db7126ed9a39f9bee434a508043] > + stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > + f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > + c20d8c197454068da758a83e09d93683f520d681, > + a1073aad497d0d071a71f61b721966a176d50c08, > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > + a1073aad497d0d071a71f61b721966a176d50c08] > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] > Thank you for your analysis result ! I applied it. I checked 27c24fda62b601d6f9ca5e992502578c4310876f is able to apply cleanly to stable/5.10 tree or not. Unfortunately it need to fix conflicts. git-am shows following two errors. Applying: Bluetooth: switch to lock_sock in SCO Checking patch net/bluetooth/sco.c... error: while searching for: BT_DBG("sock %p state %d", sk, sk->sk_state); bh_lock_sock(sk); sk->sk_err = ETIMEDOUT; sk->sk_state_change(sk); bh_unlock_sock(sk); sco_sock_kill(sk); sock_put(sk); error: patch failed: net/bluetooth/sco.c:93 error: while searching for: if (sk) { sock_hold(sk); bh_lock_sock(sk); sco_sock_clear_timer(sk); sco_chan_del(sk, err); bh_unlock_sock(sk); sco_sock_kill(sk); sock_put(sk); error: patch failed: net/bluetooth/sco.c:193 > Best regards, > Pavel > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#7015): https://lists.cip-project.org/g/cip-dev/message/7015 > Mute This Topic: https://lists.cip-project.org/mt/87299556/4520416 > Group Owner: cip-dev+owner@lists.cip-project.org > Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129101/4520416/1465703922/xyzzy [masami.ichikawa@miraclelinux.com] > -=-=-=-=-=-=-=-=-=-=-=- > Regards, -- Masami Ichikawa Cybertrust Japan Co., Ltd. Email :masami.ichikawa@cybertrust.co.jp :masami.ichikawa@miraclelinux.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2021-3640: UAF in sco_send_frame function was Re: [cip-dev] New CVE entries in this week 2021-11-25 14:22 ` Masami Ichikawa @ 2021-11-26 10:02 ` Pavel Machek 2021-11-26 13:39 ` Masami Ichikawa 0 siblings, 1 reply; 6+ messages in thread From: Pavel Machek @ 2021-11-26 10:02 UTC (permalink / raw) To: cip-dev [-- Attachment #1: Type: text/plain, Size: 5758 bytes --] Hi! > > > Interesting. > > > > > > commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 > > > Author: Takashi Iwai <tiwai@suse.de> > > > > > > Says: > > > > > > This should be the last piece for fixing CVE-2021-3640 after a few > > > already queued fixes. > > > > > > Which means more than 99c23da0eed is needed to fix this one, > > > unfortunately it does not give us good way to identify what commits > > > are needed. > > > > Aha, but we have required information in > > cip-kernel-sec/issues/CVE-2021-3640.yml. It lists patches that should > > be fixing this. > > > > Some searching in the trees reveals that one of those patches is buggy > > itself, and additionaly 49d8a5606428ca0962d09050a5af81461ff90fbb is > > needed. > > > > The patches fixing this are: > > > > ~ stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > > f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > > 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > c20d8c197454068da758a83e09d93683f520d681, > > a1073aad497d0d071a71f61b721966a176d50c08] > > > > But we still miss backport of 27c24fda62b6 ("Bluetooth: switch to > > lock_sock in SCO") to 5.10, which has its own prerequisites > > according to the changelog. AFAICT those prerequisites are > > 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab and > > ba316be1b6a00db7126ed9a39f9bee434a508043, and both are in 5.10. > > > > I'm not sure how to express this in yml cleanly. I came with this: > > > > diff --git a/issues/CVE-2021-3640.yml b/issues/CVE-2021-3640.yml > > index fb52d5a..d386093 100644 > > --- a/issues/CVE-2021-3640.yml > > +++ b/issues/CVE-2021-3640.yml > > @@ -23,9 +23,23 @@ comments: > > there is no fixed information as of 2021/07/26. > > Fixed in bluetooth-next tree. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951. > > ubuntu/sbeattie: Possibly addressed by Desmond Cheong Zhi Xi's patchset. > > + pavel: We are one patch away from fixing this 5.10, 27c24fda62b6 is needed. > > fixed-by: > > - mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > > - stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > > + mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951, > > + e04480920d1eec9c061841399aa6f35b6f987d8b, > > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > > + 49d8a5606428ca0962d09050a5af81461ff90fbb, > > + ba316be1b6a00db7126ed9a39f9bee434a508043, > > + 27c24fda62b601d6f9ca5e992502578c4310876f, > > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > > + ba316be1b6a00db7126ed9a39f9bee434a508043] > > + stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > > + f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > + c20d8c197454068da758a83e09d93683f520d681, > > + a1073aad497d0d071a71f61b721966a176d50c08, > > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > + a1073aad497d0d071a71f61b721966a176d50c08] > > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] > > > > Thank you for your analysis result ! I applied it. > > I checked 27c24fda62b601d6f9ca5e992502578c4310876f is able to apply > cleanly to stable/5.10 tree or not. Unfortunately it need to fix > conflicts. git-am shows following two errors. As far as I can tell, logic is quite simple there and the patch would look like this. Whether the final result works and closes the security hole is different question. Best regards, Pavel commit e077740ddfa22385d53700898ea325068ca4cc6b Author: Pavel Machek <pavel@ucw.cz> Date: Thu Nov 25 14:14:04 2021 +0100 Cherry pick 27c24fda62b6 ("Bluetooth: switch to lock_sock in SCO") to close CVE-2021-3640. diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c index 2f2b8ddc4dd5..cf165b0d15f2 100644 --- a/net/bluetooth/sco.c +++ b/net/bluetooth/sco.c @@ -93,10 +93,10 @@ static void sco_sock_timeout(struct work_struct *work) BT_DBG("sock %p state %d", sk, sk->sk_state); - bh_lock_sock(sk); + lock_sock(sk); sk->sk_err = ETIMEDOUT; sk->sk_state_change(sk); - bh_unlock_sock(sk); + release_sock(sk); sock_put(sk); } @@ -193,10 +193,10 @@ static void sco_conn_del(struct hci_conn *hcon, int err) if (sk) { sock_hold(sk); - bh_lock_sock(sk); + lock_sock(sk); sco_sock_clear_timer(sk); sco_chan_del(sk, err); - bh_unlock_sock(sk); + release_sock(sk); sock_put(sk); } @@ -1108,10 +1108,10 @@ static void sco_conn_ready(struct sco_conn *conn) if (sk) { sco_sock_clear_timer(sk); - bh_lock_sock(sk); + lock_sock(sk); sk->sk_state = BT_CONNECTED; sk->sk_state_change(sk); - bh_unlock_sock(sk); + release_sock(sk); } else { sco_conn_lock(conn); @@ -1126,12 +1126,12 @@ static void sco_conn_ready(struct sco_conn *conn) return; } - bh_lock_sock(parent); + lock_sock(parent); sk = sco_sock_alloc(sock_net(parent), NULL, BTPROTO_SCO, GFP_ATOMIC, 0); if (!sk) { - bh_unlock_sock(parent); + release_sock(parent); sco_conn_unlock(conn); return; } @@ -1152,7 +1152,7 @@ static void sco_conn_ready(struct sco_conn *conn) /* Wake up parent */ parent->sk_data_ready(parent); - bh_unlock_sock(parent); + release_sock(parent); sco_conn_unlock(conn); } -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: CVE-2021-3640: UAF in sco_send_frame function was Re: [cip-dev] New CVE entries in this week 2021-11-26 10:02 ` Pavel Machek @ 2021-11-26 13:39 ` Masami Ichikawa 0 siblings, 0 replies; 6+ messages in thread From: Masami Ichikawa @ 2021-11-26 13:39 UTC (permalink / raw) To: cip-dev Hi ! On Fri, Nov 26, 2021 at 7:03 PM Pavel Machek <pavel@denx.de> wrote: > > Hi! > > > > Interesting. > > > > > > > > commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 > > > > Author: Takashi Iwai <tiwai@suse.de> > > > > > > > > Says: > > > > > > > > This should be the last piece for fixing CVE-2021-3640 after a few > > > > already queued fixes. > > > > > > > > Which means more than 99c23da0eed is needed to fix this one, > > > > unfortunately it does not give us good way to identify what commits > > > > are needed. > > > > > > Aha, but we have required information in > > > cip-kernel-sec/issues/CVE-2021-3640.yml. It lists patches that should > > > be fixing this. > > > > > > Some searching in the trees reveals that one of those patches is buggy > > > itself, and additionaly 49d8a5606428ca0962d09050a5af81461ff90fbb is > > > needed. > > > > > > The patches fixing this are: > > > > > > ~ stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > > > f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > > > 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > > c20d8c197454068da758a83e09d93683f520d681, > > > a1073aad497d0d071a71f61b721966a176d50c08] > > > > > > But we still miss backport of 27c24fda62b6 ("Bluetooth: switch to > > > lock_sock in SCO") to 5.10, which has its own prerequisites > > > according to the changelog. AFAICT those prerequisites are > > > 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab and > > > ba316be1b6a00db7126ed9a39f9bee434a508043, and both are in 5.10. > > > > > > I'm not sure how to express this in yml cleanly. I came with this: > > > > > > diff --git a/issues/CVE-2021-3640.yml b/issues/CVE-2021-3640.yml > > > index fb52d5a..d386093 100644 > > > --- a/issues/CVE-2021-3640.yml > > > +++ b/issues/CVE-2021-3640.yml > > > @@ -23,9 +23,23 @@ comments: > > > there is no fixed information as of 2021/07/26. > > > Fixed in bluetooth-next tree. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951. > > > ubuntu/sbeattie: Possibly addressed by Desmond Cheong Zhi Xi's patchset. > > > + pavel: We are one patch away from fixing this 5.10, 27c24fda62b6 is needed. > > > fixed-by: > > > - mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > > > - stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de] > > > + mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951, > > > + e04480920d1eec9c061841399aa6f35b6f987d8b, > > > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > > > + 49d8a5606428ca0962d09050a5af81461ff90fbb, > > > + ba316be1b6a00db7126ed9a39f9bee434a508043, > > > + 27c24fda62b601d6f9ca5e992502578c4310876f, > > > + 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab, > > > + ba316be1b6a00db7126ed9a39f9bee434a508043] > > > + stable/5.10: [4dfba42604f08a505f1a1efc69ec5207ea6243de, > > > + f2f856b65ac4b77049c76c0e89ecd3a177e9fcd1, > > > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > > + c20d8c197454068da758a83e09d93683f520d681, > > > + a1073aad497d0d071a71f61b721966a176d50c08, > > > + 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f, > > > + a1073aad497d0d071a71f61b721966a176d50c08] > > > stable/5.14: [2c2b295af72e4e30d17556375e100ae65ac0b896] > > > stable/5.15: [b990c219c4c9d4993ef65ea9db73d9497e70f697] > > > stable/5.4: [d416020f1a9cc5f903ae66649b2c56d9ad5256ab] > > > > > > > Thank you for your analysis result ! I applied it. > > > > I checked 27c24fda62b601d6f9ca5e992502578c4310876f is able to apply > > cleanly to stable/5.10 tree or not. Unfortunately it need to fix > > conflicts. git-am shows following two errors. > > As far as I can tell, logic is quite simple there and the patch would > look like this. Whether the final result works and closes the security > hole is different question. > Thank you for the patch ! Yes, applying code and works properly is different question. however, your patch is LGTM. > Best regards, > Pavel > commit e077740ddfa22385d53700898ea325068ca4cc6b > Author: Pavel Machek <pavel@ucw.cz> > Date: Thu Nov 25 14:14:04 2021 +0100 > > Cherry pick 27c24fda62b6 ("Bluetooth: switch to lock_sock in SCO") to > close CVE-2021-3640. > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c > index 2f2b8ddc4dd5..cf165b0d15f2 100644 > --- a/net/bluetooth/sco.c > +++ b/net/bluetooth/sco.c > @@ -93,10 +93,10 @@ static void sco_sock_timeout(struct work_struct *work) > > BT_DBG("sock %p state %d", sk, sk->sk_state); > > - bh_lock_sock(sk); > + lock_sock(sk); > sk->sk_err = ETIMEDOUT; > sk->sk_state_change(sk); > - bh_unlock_sock(sk); > + release_sock(sk); > > sock_put(sk); > } > @@ -193,10 +193,10 @@ static void sco_conn_del(struct hci_conn *hcon, int err) > > if (sk) { > sock_hold(sk); > - bh_lock_sock(sk); > + lock_sock(sk); > sco_sock_clear_timer(sk); > sco_chan_del(sk, err); > - bh_unlock_sock(sk); > + release_sock(sk); > sock_put(sk); > } > > @@ -1108,10 +1108,10 @@ static void sco_conn_ready(struct sco_conn *conn) > > if (sk) { > sco_sock_clear_timer(sk); > - bh_lock_sock(sk); > + lock_sock(sk); > sk->sk_state = BT_CONNECTED; > sk->sk_state_change(sk); > - bh_unlock_sock(sk); > + release_sock(sk); > } else { > sco_conn_lock(conn); > > @@ -1126,12 +1126,12 @@ static void sco_conn_ready(struct sco_conn *conn) > return; > } > > - bh_lock_sock(parent); > + lock_sock(parent); > > sk = sco_sock_alloc(sock_net(parent), NULL, > BTPROTO_SCO, GFP_ATOMIC, 0); > if (!sk) { > - bh_unlock_sock(parent); > + release_sock(parent); > sco_conn_unlock(conn); > return; > } > @@ -1152,7 +1152,7 @@ static void sco_conn_ready(struct sco_conn *conn) > /* Wake up parent */ > parent->sk_data_ready(parent); > > - bh_unlock_sock(parent); > + release_sock(parent); > > sco_conn_unlock(conn); > } > > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#7021): https://lists.cip-project.org/g/cip-dev/message/7021 > Mute This Topic: https://lists.cip-project.org/mt/87299556/4520416 > Group Owner: cip-dev+owner@lists.cip-project.org > Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129101/4520416/1465703922/xyzzy [masami.ichikawa@miraclelinux.com] > -=-=-=-=-=-=-=-=-=-=-=- > Regards, -- Masami Ichikawa Cybertrust Japan Co., Ltd. Email :masami.ichikawa@cybertrust.co.jp :masami.ichikawa@miraclelinux.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-26 13:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-25 2:41 New CVE entries in this week Masami Ichikawa
2021-11-25 9:14 ` [cip-dev] " Pavel Machek
[not found] ` <16BABF37827ACD8B.14741@lists.cip-project.org>
2021-11-25 9:53 ` CVE-2021-3640: UAF in sco_send_frame function was " Pavel Machek
2021-11-25 14:22 ` Masami Ichikawa
2021-11-26 10:02 ` Pavel Machek
2021-11-26 13:39 ` Masami Ichikawa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox