[PATCH OpenHarmony-4.19 0/9] OpenHarmony-4.19 cve bugfix 0723

Yu Changchun

23 Jul 2021 23 Jul '21

2:18 a.m.

There are cves based on OpenHarmony-4.19 as follows: CVE: CVE-2021-3573 CVE: CVE-2021-0129 CVE: CVE-2021-0512 CVE: CVE-2021-3587 CVE: CVE-2021-3564 CVE: CVE-2020-36385 CVE: CVE-2021-33200 Daniel Borkmann (3): bpf: Wrap aux data inside bpf_sanitize_info container bpf: Fix mask direction swap upon off reg sign change bpf: No need to simulate speculative domain for immediates Jason Gunthorpe (1): RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy Krzysztof Kozlowski (1): nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect Lin Ma (2): Bluetooth: fix the erroneous flush_work() order Bluetooth: use correct lock to prevent UAF of hdev object Luiz Augusto von Dentz (1): Bluetooth: SMP: Fail if remote and local public keys are identical Will McVicker (1): HID: make arrays usage and value to be the same drivers/hid/hid-core.c | 6 +-- drivers/infiniband/core/ucma.c | 78 +++++++++++++--------------------- kernel/bpf/verifier.c | 46 ++++++++++++-------- net/bluetooth/hci_core.c | 7 ++- net/bluetooth/hci_sock.c | 4 +- net/bluetooth/smp.c | 9 ++++ net/nfc/llcp_sock.c | 2 + 7 files changed, 79 insertions(+), 73 deletions(-) -- 2.25.1

Show replies by date

Yu Changchun

23 Jul 23 Jul

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 1/9] bpf: Wrap aux data inside bpf_sanitize_info container

From: Daniel Borkmann mainline inclusion from mainline-v5.13-rc4 commit 3d0220f6861d713213b015b582e9f21e5b28d2e0 category: bugfix issue: #I421HX CVE: CVE-2021-33200 -------------------------------- Add a container structure struct bpf_sanitize_info which holds the current aux info, and update call-sites to sanitize_ptr_alu() to pass it in. This is needed for passing in additional state later on. Signed-off-by: Daniel Borkmann Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Yang Yingliang Reviewed-by: Kuohai Xu Reviewed-by: Xiu Jianfeng Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- kernel/bpf/verifier.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 760b4e316..49c6e125d 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2815,15 +2815,19 @@ static bool sanitize_needed(u8 opcode) return opcode == BPF_ADD || opcode == BPF_SUB; } +struct bpf_sanitize_info { + struct bpf_insn_aux_data aux; +}; + static int sanitize_ptr_alu(struct bpf_verifier_env *env, struct bpf_insn *insn, const struct bpf_reg_state *ptr_reg, const struct bpf_reg_state *off_reg, struct bpf_reg_state *dst_reg, - struct bpf_insn_aux_data *tmp_aux, + struct bpf_sanitize_info *info, const bool commit_window) { - struct bpf_insn_aux_data *aux = commit_window ? cur_aux(env) : tmp_aux; + struct bpf_insn_aux_data *aux = commit_window ? cur_aux(env) : &info->aux; struct bpf_verifier_state *vstate = env->cur_state; bool off_is_imm = tnum_is_const(off_reg->var_off); bool off_is_neg = off_reg->smin_value < 0; @@ -2852,8 +2856,8 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, /* In commit phase we narrow the masking window based on * the observed pointer move after the simulated operation. */ - alu_state = tmp_aux->alu_state; - alu_limit = abs(tmp_aux->alu_limit - alu_limit); + alu_state = info->aux.alu_state; + alu_limit = abs(info->aux.alu_limit - alu_limit); } else { alu_state = off_is_neg ? BPF_ALU_NEG_VALUE : 0; alu_state |= off_is_imm ? BPF_ALU_IMMEDIATE : 0; @@ -3014,7 +3018,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, smin_ptr = ptr_reg->smin_value, smax_ptr = ptr_reg->smax_value; u64 umin_val = off_reg->umin_value, umax_val = off_reg->umax_value, umin_ptr = ptr_reg->umin_value, umax_ptr = ptr_reg->umax_value; - struct bpf_insn_aux_data tmp_aux = {}; + struct bpf_sanitize_info info = {}; u8 opcode = BPF_OP(insn->code); u32 dst = insn->dst_reg; int ret; @@ -3066,7 +3070,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, if (sanitize_needed(opcode)) { ret = sanitize_ptr_alu(env, insn, ptr_reg, off_reg, dst_reg, - &tmp_aux, false); + &info, false); if (ret < 0) return sanitize_err(env, insn, ret, off_reg, dst_reg); } @@ -3208,7 +3212,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, return -EACCES; if (sanitize_needed(opcode)) { ret = sanitize_ptr_alu(env, insn, dst_reg, off_reg, dst_reg, - &tmp_aux, true); + &info, true); if (ret < 0) return sanitize_err(env, insn, ret, off_reg, dst_reg); } -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 2/9] bpf: Fix mask direction swap upon off reg sign change

From: Daniel Borkmann mainline inclusion from mainline-v5.13-rc4 commit bb01a1bba579b4b1c5566af24d95f1767859771e category: bugfix issue: #I421HX CVE: CVE-2021-33200 -------------------------------- Masking direction as indicated via mask_to_left is considered to be calculated once and then used to derive pointer limits. Thus, this needs to be placed into bpf_sanitize_info instead so we can pass it to sanitize_ptr_alu() call after the pointer move. Piotr noticed a corner case where the off reg causes masking direction change which then results in an incorrect final aux->alu_limit. Fixes: 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask") Reported-by: Piotr Krysiuk Signed-off-by: Daniel Borkmann Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Yang Yingliang Reviewed-by: Kuohai Xu Reviewed-by: Xiu Jianfeng Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- kernel/bpf/verifier.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 49c6e125d..2c37b5f27 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2738,18 +2738,10 @@ enum { }; static int retrieve_ptr_limit(const struct bpf_reg_state *ptr_reg, - const struct bpf_reg_state *off_reg, - u32 *alu_limit, u8 opcode) + u32 *alu_limit, bool mask_to_left) { - bool off_is_neg = off_reg->smin_value < 0; - bool mask_to_left = (opcode == BPF_ADD && off_is_neg) || - (opcode == BPF_SUB && !off_is_neg); u32 max = 0, ptr_limit = 0; - if (!tnum_is_const(off_reg->var_off) && - (off_reg->smin_value < 0) != (off_reg->smax_value < 0)) - return REASON_BOUNDS; - switch (ptr_reg->type) { case PTR_TO_STACK: /* Offset 0 is out-of-bounds, but acceptable start for the @@ -2817,6 +2809,7 @@ static bool sanitize_needed(u8 opcode) struct bpf_sanitize_info { struct bpf_insn_aux_data aux; + bool mask_to_left; }; static int sanitize_ptr_alu(struct bpf_verifier_env *env, @@ -2848,7 +2841,16 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, if (vstate->speculative) goto do_sim; - err = retrieve_ptr_limit(ptr_reg, off_reg, &alu_limit, opcode); + if (!commit_window) { + if (!tnum_is_const(off_reg->var_off) && + (off_reg->smin_value < 0) != (off_reg->smax_value < 0)) + return REASON_BOUNDS; + + info->mask_to_left = (opcode == BPF_ADD && off_is_neg) || + (opcode == BPF_SUB && !off_is_neg); + } + + err = retrieve_ptr_limit(ptr_reg, &alu_limit, info->mask_to_left); if (err < 0) return err; -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 3/9] bpf: No need to simulate speculative domain for immediates

From: Daniel Borkmann mainline inclusion from mainline-v5.13-rc4 commit a7036191277f9fa68d92f2071ddc38c09b1e5ee5 category: bugfix issue: #I421HX CVE: CVE-2021-33200 -------------------------------- In 801c6058d14a ("bpf: Fix leakage of uninitialized bpf stack under speculation") we replaced masking logic with direct loads of immediates if the register is a known constant. Given in this case we do not apply any masking, there is also no reason for the operation to be truncated under the speculative domain. Therefore, there is also zero reason for the verifier to branch-off and simulate this case, it only needs to do it for unknown but bounded scalars. As a side-effect, this also enables few test cases that were previously rejected due to simulation under zero truncation. Signed-off-by: Daniel Borkmann Reviewed-by: Piotr Krysiuk Acked-by: Alexei Starovoitov Signed-off-by: Yang Yingliang Reviewed-by: Kuohai Xu Reviewed-by: Xiu Jianfeng Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- kernel/bpf/verifier.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 2c37b5f27..740732f6b 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2874,8 +2874,12 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, /* If we're in commit phase, we're done here given we already * pushed the truncated dst_reg into the speculative verification * stack. + * + * Also, when register is a known constant, we rewrite register-based + * operation to immediate-based, and thus do not need masking (and as + * a consequence, do not need to simulate the zero-truncation either). */ - if (commit_window) + if (commit_window || off_is_imm) return 0; /* Simulate and find potential out-of-bounds access under -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 4/9] RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy

From: Jason Gunthorpe mainline inclusion from mainline-v5.10-rc1 commit f5449e74802c1112dea984aec8af7a33c4516af1 category: bugfix issue: #I421HO CVE: CVE-2020-36385 -------------------------------- ucma_destroy_id() assumes that all things accessing the ctx will do so via the xarray. This assumption violated only in the case the FD is being closed, then the ctx is reached via the ctx_list. Normally this is OK since ucma_destroy_id() cannot run concurrenty with release(), however with ucma_migrate_id() is involved this can violated as the close of the 2nd FD can run concurrently with destroy on the first: CPU0 CPU1 ucma_destroy_id(fda) ucma_migrate_id(fda -> fdb) ucma_get_ctx() xa_lock() _ucma_find_context() xa_erase() xa_unlock() xa_lock() ctx->file = new_file list_move() xa_unlock() ucma_put_ctx() ucma_close(fdb) _destroy_id() kfree(ctx) _destroy_id() wait_for_completion() // boom, ctx was freed The ctx->file must be modified under the handler and xa_lock, and prior to modification the ID must be rechecked that it is still reachable from cur_file, ie there is no parallel destroy or migrate. To make this work remove the double locking and streamline the control flow. The double locking was obsoleted by the handler lock now directly preventing new uevents from being created, and the ctx_list cannot be read while holding fgets on both files. Removing the double locking also removes the need to check for the same file. Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()") Link: https://lore.kernel.org/r/0-v1-05c5a4090305+3a872-ucma_syz_migrate_jgg@nvidi... Reported-and-tested-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Yang Yingliang Reviewed-by: Xiu Jianfeng Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- drivers/infiniband/core/ucma.c | 78 +++++++++++++--------------------- 1 file changed, 29 insertions(+), 49 deletions(-) diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c index 01052de6b..74086abd3 100644 --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -1582,45 +1582,15 @@ static ssize_t ucma_leave_multicast(struct ucma_file *file, return ret; } -static void ucma_lock_files(struct ucma_file *file1, struct ucma_file *file2) -{ - /* Acquire mutex's based on pointer comparison to prevent deadlock. */ - if (file1 < file2) { - mutex_lock(&file1->mut); - mutex_lock_nested(&file2->mut, SINGLE_DEPTH_NESTING); - } else { - mutex_lock(&file2->mut); - mutex_lock_nested(&file1->mut, SINGLE_DEPTH_NESTING); - } -} - -static void ucma_unlock_files(struct ucma_file *file1, struct ucma_file *file2) -{ - if (file1 < file2) { - mutex_unlock(&file2->mut); - mutex_unlock(&file1->mut); - } else { - mutex_unlock(&file1->mut); - mutex_unlock(&file2->mut); - } -} - -static void ucma_move_events(struct ucma_context *ctx, struct ucma_file *file) -{ - struct ucma_event *uevent, *tmp; - - list_for_each_entry_safe(uevent, tmp, &ctx->file->event_list, list) - if (uevent->ctx == ctx) - list_move_tail(&uevent->list, &file->event_list); -} - static ssize_t ucma_migrate_id(struct ucma_file *new_file, const char __user *inbuf, int in_len, int out_len) { struct rdma_ucm_migrate_id cmd; struct rdma_ucm_migrate_resp resp; + struct ucma_event *uevent, *tmp; struct ucma_context *ctx; + LIST_HEAD(event_list); struct fd f; struct ucma_file *cur_file; int ret = 0; @@ -1636,42 +1606,52 @@ static ssize_t ucma_migrate_id(struct ucma_file *new_file, ret = -EINVAL; goto file_put; } + cur_file = f.file->private_data; /* Validate current fd and prevent destruction of id. */ - ctx = ucma_get_ctx(f.file->private_data, cmd.id); + ctx = ucma_get_ctx(cur_file, cmd.id); if (IS_ERR(ctx)) { ret = PTR_ERR(ctx); goto file_put; } - cur_file = ctx->file; - if (cur_file == new_file) { - mutex_lock(&cur_file->mut); - resp.events_reported = ctx->events_reported; - mutex_unlock(&cur_file->mut); - goto response; - } - /* - * Migrate events between fd's, maintaining order, and avoiding new - * events being added before existing events. + * ctx->file can only be changed under the handler & xa_lock. xa_load() + * must be checked again to ensure the ctx hasn't begun destruction + * since the ucma_get_ctx(). */ - ucma_lock_files(cur_file, new_file); mutex_lock(&mut); - list_move_tail(&ctx->list, &new_file->ctx_list); - ucma_move_events(ctx, new_file); + if (_ucma_find_context(cmd.id, cur_file) != ctx) { + mutex_unlock(&mut); + ret = -ENOENT; + goto err_unlock; + } ctx->file = new_file; + mutex_unlock(&mut); + + mutex_lock(&cur_file->mut); + list_del(&ctx->list); + /* + * At this point lock_handler() prevents addition of new uevents for + * this ctx. + */ + list_for_each_entry_safe(uevent, tmp, &cur_file->event_list, list) + if (uevent->ctx == ctx) + list_move_tail(&uevent->list, &event_list); resp.events_reported = ctx->events_reported; + mutex_unlock(&cur_file->mut); - mutex_unlock(&mut); - ucma_unlock_files(cur_file, new_file); + mutex_lock(&new_file->mut); + list_add_tail(&ctx->list, &new_file->ctx_list); + list_splice_tail(&event_list, &new_file->event_list); + mutex_unlock(&new_file->mut); -response: if (copy_to_user(u64_to_user_ptr(cmd.response), &resp, sizeof(resp))) ret = -EFAULT; +err_unlock: ucma_put_ctx(ctx); file_put: fdput(f); -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 5/9] Bluetooth: fix the erroneous flush_work() order

From: Lin Ma stable inclusion from linux-4.19.194 commit 64700748e8a7af4883538c72ada57999d9a78e92 category: bugfix issue: #I421EH CVE: CVE-2021-3564 -------------------------------- commit 6a137caec23aeb9e036cdfd8a46dd8a366460e5d upstream. In the cleanup routine for failed initialization of HCI device, the flush_work(&hdev->rx_work) need to be finished before the flush_work(&hdev->cmd_work). Otherwise, the hci_rx_work() can possibly invoke new cmd_work and cause a bug, like double free, in late processings. This was assigned CVE-2021-3564. This patch reorder the flush_work() to fix this bug. Cc: Marcel Holtmann Cc: Johan Hedberg Cc: Luiz Augusto von Dentz Cc: "David S. Miller" Cc: Jakub Kicinski Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Lin Ma Signed-off-by: Hao Xiong Cc: stable Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- net/bluetooth/hci_core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index e03faca84..fb47fe995 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -1496,8 +1496,13 @@ static int hci_dev_do_open(struct hci_dev *hdev) } else { /* Init failed, cleanup */ flush_work(&hdev->tx_work); - flush_work(&hdev->cmd_work); + + /* Since hci_rx_work() is possible to awake new cmd_work + * it should be flushed first to avoid unexpected call of + * hci_cmd_work() + */ flush_work(&hdev->rx_work); + flush_work(&hdev->cmd_work); skb_queue_purge(&hdev->cmd_q); skb_queue_purge(&hdev->rx_q); -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 6/9] nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect

From: Krzysztof Kozlowski stable inclusion from linux-4.19.194 commit 93e4ac2a9979a9a4ecc158409ed9c3044dc0ae1f category: bugfix issue: #I421HG CVE: CVE-2021-3587 -------------------------------- commit 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream. It's possible to trigger NULL pointer dereference by local unprivileged user, when calling getsockname() after failed bind() (e.g. the bind fails because LLCP_SAP_MAX used as SAP): BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014 Call Trace: llcp_sock_getname+0xb1/0xe0 __sys_getpeername+0x95/0xc0 ? lockdep_hardirqs_on_prepare+0xd5/0x180 ? syscall_enter_from_user_mode+0x1c/0x40 __x64_sys_getpeername+0x11/0x20 do_syscall_64+0x36/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae This can be reproduced with Syzkaller C repro (bind followed by getpeername): https://syzkaller.appspot.com/x/repro.c?x=14def446e00000 Cc: Fixes: d646960f7986 ("NFC: Initial LLCP support") Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com Reported-by: butt3rflyh4ck Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonica... Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- net/nfc/llcp_sock.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c index 59de4f54d..23f7116d1 100644 --- a/net/nfc/llcp_sock.c +++ b/net/nfc/llcp_sock.c @@ -122,6 +122,7 @@ static int llcp_sock_bind(struct socket *sock, struct sockaddr *addr, int alen) if (!llcp_sock->service_name) { nfc_llcp_local_put(llcp_sock->local); llcp_sock->local = NULL; + llcp_sock->dev = NULL; ret = -ENOMEM; goto put_dev; } @@ -131,6 +132,7 @@ static int llcp_sock_bind(struct socket *sock, struct sockaddr *addr, int alen) llcp_sock->local = NULL; kfree(llcp_sock->service_name); llcp_sock->service_name = NULL; + llcp_sock->dev = NULL; ret = -EADDRINUSE; goto put_dev; } -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 7/9] HID: make arrays usage and value to be the same

From: Will McVicker stable inclusion from linux-4.19.178 commit ffca531f71d078c6caf752d64bc2a592f420f7c6 category: bugfix issue: #I421GE CVE: CVE-2021-0512 -------------------------------- commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f upstream. The HID subsystem allows an "HID report field" to have a different number of "values" and "usages" when it is allocated. When a field struct is created, the size of the usage array is guaranteed to be at least as large as the values array, but it may be larger. This leads to a potential out-of-bounds write in __hidinput_change_resolution_multipliers() and an out-of-bounds read in hidinput_count_leds(). To fix this, let's make sure that both the usage and value arrays are the same size. Cc: stable@vger.kernel.org Signed-off-by: Will McVicker Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- drivers/hid/hid-core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 05122167d..bde5cef32 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -93,7 +93,7 @@ EXPORT_SYMBOL_GPL(hid_register_report); * Register a new field for this report. */ -static struct hid_field *hid_register_field(struct hid_report *report, unsigned usages, unsigned values) +static struct hid_field *hid_register_field(struct hid_report *report, unsigned usages) { struct hid_field *field; @@ -104,7 +104,7 @@ static struct hid_field *hid_register_field(struct hid_report *report, unsigned field = kzalloc((sizeof(struct hid_field) + usages * sizeof(struct hid_usage) + - values * sizeof(unsigned)), GFP_KERNEL); + usages * sizeof(unsigned)), GFP_KERNEL); if (!field) return NULL; @@ -300,7 +300,7 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign usages = max_t(unsigned, parser->local.usage_index, parser->global.report_count); - field = hid_register_field(report, usages, parser->global.report_count); + field = hid_register_field(report, usages); if (!field) return 0; -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 8/9] Bluetooth: SMP: Fail if remote and local public keys are identical

From: Luiz Augusto von Dentz stable inclusion from linux-4.19.192 commit 30126d4ba73119565f1748b116b9869ac6bbda6b category: bugfix issue: #I421FG CVE: CVE-2021-0129 -------------------------------- commit 6d19628f539fccf899298ff02ee4c73e4bf6df3f upstream. This fails the pairing procedure when both remote and local non-debug public keys are identical. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- net/bluetooth/smp.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c index cc2f7ca91..719ae1dff 100644 --- a/net/bluetooth/smp.c +++ b/net/bluetooth/smp.c @@ -2703,6 +2703,15 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb) if (skb->len < sizeof(*key)) return SMP_INVALID_PARAMS; + /* Check if remote and local public keys are the same and debug key is + * not in use. + */ + if (!test_bit(SMP_FLAG_DEBUG_KEY, &smp->flags) && + !crypto_memneq(key, smp->local_pk, 64)) { + bt_dev_err(hdev, "Remote and local public keys are identical"); + return SMP_UNSPECIFIED; + } + memcpy(smp->remote_pk, key, 64); if (test_bit(SMP_FLAG_REMOTE_OOB, &smp->flags)) { -- 2.25.1

Yu Changchun

2:18 a.m.

New subject: [PATCH OpenHarmony-4.19 9/9] Bluetooth: use correct lock to prevent UAF of hdev object

From: Lin Ma stable inclusion from linux-4.19.194 commit 2b9e9c2ed0f1910b5201c5d37b355b60201df415 category: bugfix issue: #I421FB CVE: CVE-2021-3573 -------------------------------- commit e305509e678b3a4af2b3cfd410f409f7cdaabb52 upstream. The hci_sock_dev_event() function will cleanup the hdev object for sockets even if this object may still be in used within the hci_sock_bound_ioctl() function, result in UAF vulnerability. This patch replace the BH context lock to serialize these affairs and prevent the race condition. Signed-off-by: Lin Ma Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Yang Yingliang Signed-off-by: Yu Changchun --- net/bluetooth/hci_sock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c index e506c51ff..06156de24 100644 --- a/net/bluetooth/hci_sock.c +++ b/net/bluetooth/hci_sock.c @@ -755,7 +755,7 @@ void hci_sock_dev_event(struct hci_dev *hdev, int event) /* Detach sockets from device */ read_lock(&hci_sk_list.lock); sk_for_each(sk, &hci_sk_list.head) { - bh_lock_sock_nested(sk); + lock_sock(sk); if (hci_pi(sk)->hdev == hdev) { hci_pi(sk)->hdev = NULL; sk->sk_err = EPIPE; @@ -764,7 +764,7 @@ void hci_sock_dev_event(struct hci_dev *hdev, int event) hci_dev_put(hdev); } - bh_unlock_sock(sk); + release_sock(sk); } read_unlock(&hci_sk_list.lock); } -- 2.25.1

weiyongjun (A)

27 Jul 27 Jul

3:06 a.m.

在 2021/7/23 10:18, Yu Changchun 写道:

...

There are cves based on OpenHarmony-4.19 as follows:

CVE: CVE-2021-3573 CVE: CVE-2021-0129 CVE: CVE-2021-0512 CVE: CVE-2021-3587 CVE: CVE-2021-3564 CVE: CVE-2020-36385 CVE: CVE-2021-33200

Daniel Borkmann (3): bpf: Wrap aux data inside bpf_sanitize_info container bpf: Fix mask direction swap upon off reg sign change bpf: No need to simulate speculative domain for immediates

Jason Gunthorpe (1): RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy

Krzysztof Kozlowski (1): nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect

Lin Ma (2): Bluetooth: fix the erroneous flush_work() order Bluetooth: use correct lock to prevent UAF of hdev object

Luiz Augusto von Dentz (1): Bluetooth: SMP: Fail if remote and local public keys are identical

Will McVicker (1): HID: make arrays usage and value to be the same

Looks good to me

1210

Age (days ago)

1214

Last active (days ago)

List overview

10 comments

2 participants

participants (2)

weiyongjun (A)
Yu Changchun

[PATCH OpenHarmony-4.19 0/9] OpenHarmony-4.19 cve bugfix 0723

tags

participants (2)