Date
1 - 4 of 4
New CVE entries this week
Masami Ichikawa
Hi !
It's this week's CVE report. This week reported 6 new CVEs and 10 updated CVEs. * New CVEs CVE-2022-2196: KVM: VMX: Execute IBPB on emulated VM-exit when guest has IBRS CVSS v3 score is not provided Introduced by commit 5c911be ("KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02") in 5.8-rc1. This commit fixes commit 15d4507 ("KVM/x86: Add IBPB support") in 4.16-rc1. Commit 5c911be is not backported to 4.x kernels. Fixed status mainline: [2e7eab81425ad6c875f2ed47c0ce01e78afc38a5] CVE-2022-4543: KASLR Leakage Achievable even with KPTI through Prefetch Side-Channel CVSS v3 score is not provided A user can get KASLR base address on Intel and AMD CPUs based system even if kernel enables KPTI. Fixed status Not fixed yet CVE-2022-47518: wifi: wilc1000: validate number of channels CVSS v3 score is not provided An issue was discovered in the Linux kernel before 6.0.11. Missing validation of the number of channels in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when copying the list of operating channels from Wi-Fi management frames. It looks like a vulnerable function is not present on 4.4 and 4.9. That function is present in 5.4 and 4.19 however, this driver is staging driver at that time. Also, implementation of wilc_wfi_cfg_parse_ch_attr() in 5.4 and 4.19 are different from newer code. It seems as if they are not affected. Fixed status mainline: [0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0] stable/5.10: [3eb6b89a4e9f9e44c3170d70d8d16c3c8dc8c800] stable/5.15: [7aed1dd5d221dabe3fe258f13ecf5fc7df393cbb] stable/6.0: [6195b4838e10a557859862c4e7840dc0eafdd1cd] CVE-2022-47519: wifi: wilc1000: validate length of IEEE80211_P2P_ATTR_OPER_CHANNEL attribute CVSS v3 score is not provided An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_OPER_CHANNEL in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger an out-of-bounds write when parsing the channel list attribute from Wi-Fi management frames. It looks like a vulnerable function is not present on 4.4 and 4.9. That function is present in 5.4 and 4.19 however, this driver is staging driver at that time. Also, implementation of wilc_wfi_cfg_parse_ch_attr() in 5.4 and 4.19 are different from newer code. It seems as if they are not affected. Fixed status mainline: [051ae669e4505abbe05165bebf6be7922de11f41] stable/5.10: [905f886eae4b065656a575e8a02544045cbaadcf] stable/5.15: [143232cb5a4c96d69a7d90b643568665463c6191] stable/6.0: [c4b629c29a51344a99f279e0bc0caffd25897725] CVE-2022-47520: wifi: wilc1000: validate pairwise and authentication suite offsets CVSS v3 score is not provided It looks like a vulnerable function is not present in 4.x kernels. That function is present in 5.4 however, this driver is staging driver at that time. Fixed status mainline: [cd21d99e595ec1d8721e1058dcdd4f1f7de1d793] stable/5.10: [7c6535fb4d67ea37c98a1d1d24ca33dd5ec42693] stable/5.15: [cd9c4869710bb6e38cfae4478c23e64e91438442] stable/6.0: [b3ac275fe82fb2e52085dace26ab65c91b3434b8] CVE-2022-47521: wifi: wilc1000: validate length of IEEE80211_P2P_ATTR_CHANNEL_LIST attribute CVSS v3 score is not provided An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_CHANNEL_LIST in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when parsing the operating channel attribute from Wi-Fi management frames. It looks like a vulnerable function is not present on 4.4 and 4.9. That function is present in 5.4 and 4.19 however, this driver is staging driver at that time. Also, implementation of wilc_wfi_cfg_parse_ch_attr() in 5.4 and 4.19 are different from newer code. It seems as if they are not affected. Fixed status mainline: [f9b62f9843c7b0afdaecabbcebf1dbba18599408] stable/5.10: [5a068535c0073c8402aa0755e8ef259fb98a33c5] stable/5.15: [e9de501cf70d2b508b2793ed3e7d5d5ceabd7a74] stable/6.0: [0269a353bb4bf49902c702e0b55dcab0d470f5aa] * Updated CVEs CVE-2022-3344: KVM: SVM: nested shutdown interception could lead to host crash Added 917401f ("KVM: x86: nSVM: leave nested mode on vCPU free") and f9697df2 ("KVM: x86: add kvm_leave_nested") to mainline. Fixed status mainline: [16ae56d7e0528559bf8dc9070e3bfd8ba3de80df, ed129ec9057f89d615ba0c81a4984a90345a1684, 917401f26a6af5756d89b550a8e1bd50cf42b07e, f9697df251438b0798780900e8b43bdb12a56d64] stable/5.15: [3e87cb0caa25d667a9ca2fe15fef889e43ab8f95, 6425c590d0cc6914658a630a40b7f8226aa028c3] stable/6.0: [5ca2721b7d3ed4d3da6323a2ea7339f745866d83, d40ef0a511676bd65ca9acb295430c07af59ab85] CVE-2022-3424: misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os The mainline was fixed. Fixed status mainline: [643a16a0eb1d6ac23744bb6e90a00fc21148a9dc] CVE-2022-36280: An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c Fixed in the mainline. This bug was Introduced by commit 2ac8637 ("vmwgfx: Snoop DMA transfers with non-covering sizes") in 3.2-rc1 Fixed status mainline: [4cf949c7fafe21e085a4ee386bb2dade9067316e] CVE-2022-41218: media: dvb-core: Fix UAF due to refcount races at releasing Fixed in the mainline. Fixed status mainline: [fd3d91ab1c6ab0628fe642dd570b56302c30a792] CVE-2022-4129: l2tp: missing lock when clearing sk_user_data can lead to NULL pointer dereference Added commit af295e8 ("l2tp: Don't sleep and disable BH under writer-side sk_callback_lock") to mainline. Fixed status mainline: [b68777d54fac21fc833ec26ea1a2a84f975ab035, af295e854a4e3813ffbdef26dbb6a4d6226c3ea1] CVE-2022-3545: nfp: fix use-after-free in area_cache_get() Patch was backported to 5.10, 5.15, and 5.4. Fixed status mainline: [02e1a114fdb71e59ee6770294166c30d437bf86a] stable/5.10: [eb6313c12955c58c3d3d40f086c22e44ca1c9a1b] stable/5.15: [9d933af8fef33c32799b9f2d3ff6bf58a63d7f24] stable/5.4: [3c837460f920a63165961d2b88b425703f59affb] CVE-2022-3623: mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page Patch was backported to 5.4. Fixed status mainline: [fac35ba763ed07ba93154c95ffc0c4a55023707f] stable/5.10: [fccee93eb20d72f5390432ecea7f8c16af88c850] stable/5.15: [3a44ae4afaa5318baed3c6e2959f24454e0ae4ff] stable/5.19: [86a913d55c89dd13ba070a87f61a493563e94b54] stable/5.4: [176ba4c19d1bb153aa6baaa61d586e785b7d736c] stable/6.0: [7c7c79dd5a388758f8dfa3de89b131d5d84f25fd] CVE-2022-3643: xen/netback: Ensure protocol headers don''t fall in the non-linear area Commit 7dfa764 (xen/netback: fix build warning) was added to the mainline and was backported to 5.10 and 5.4. Fixed status mainline: [ad7f402ae4f466647c3a669b8a6f3e5d4271c84a, 7dfa764e0223a324366a2a1fc056d4d9d4e95491] stable/4.14: [e173cefc814dec81e9836ecc866cdba154e693cd] stable/4.19: [44dfdecc288b8d5932e09f5e6a597a089d5a82b2, 5215a8c7a72c0c9d49de9450ad92464832e981af] stable/4.9: [1a1d9be7b36ee6cbdeb9d160038834d707256e88] stable/5.10: [49e07c0768dbebff672ee1834eff9680fc6277bf, a00444e25bbc3ff90314ebc72e9b4952b12211d9] stable/5.15: [0fe29bd92594a747a2561589bd452c259451929e] stable/5.4: [8fe1bf6f32cd5b96ddcd2a38110603fe34753e52] stable/6.0: [e8851d841fe4f29b613a00de45f39c80dbfdb975] CVE-2022-42896: Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM Commit f937b75 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm") was added to the mainline. Fixed status mainline: [711f8c3fb3db61897080468586b970c87c61d9e4, f937b758a188d6fd328a81367087eddbb2fce50f] stable/4.14: [9f4624c42db9dd854870ccb212ddd405d8c59041] stable/4.19: [a2045d57e844864605d39e6cfd2237861d800f13] stable/4.9: [c834df40af8ec156e8c3c388a08ff7381cd90d80] stable/5.10: [6b6f94fb9a74dd2891f11de4e638c6202bc89476] stable/5.15: [81035e1201e26d57d9733ac59140a3e29befbc5a] stable/5.4: [0d87bb6070361e5d1d9cb391ba7ee73413bc109b] stable/6.0: [d7efeb93213becae13c6a12e4150ce1e07bd2c49] CVE-2022-45934: Bluetooth: L2CAP: Fix u8 overflow Patch was backported to 5.10, 5.15, and 6.0. Fixed status mainline: [bcd70260ef56e0aee8a4fc6cd214a419900b0765] stable/5.10: [f3fe6817156a2ad4b06f01afab04638a34d7c9a6] stable/5.15: [19a78143961a197de8502f4f29c453b913dc3c29] stable/6.0: [5550bbf709c323194881737fd290c4bada9e6ead] 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-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@... :masami.ichikawa@... |
|
Dan Carpenter <error27@...>
[ Still going through old stuff from the holiday season ]
On Thu, Dec 22, 2022 at 07:58:48AM +0900, Masami Ichikawa wrote: CVE-2022-47518: wifi: wilc1000: validate number of channelsThis is probably something which could have been caught with static analysis. The first problem was that cfg80211_find_vendor_ie() takes a struct and casts it to a char *. Smatch correctly marks some of the struct members as user data, but loses that information when the cast happens. It is easy to hard code cfg80211_find_vendor_ie() as returning user data so we avoid this bug in the future. diff --git a/smatch_points_to_user_data.c b/smatch_points_to_user_data.c index 4267b85b53a7..f632d8c84452 100644 --- a/smatch_points_to_user_data.c +++ b/smatch_points_to_user_data.c @@ -49,7 +49,7 @@ STATE(user_data_set); static const char *returns_pointer_to_user_data[] = { "nlmsg_data", "nla_data", "memdup_user", "kmap_atomic", "skb_network_header", "cfg80211_find_elem_match", "ieee80211_bss_get_elem", "cfg80211_find_elem", - "ieee80211_bss_get_ie", + "ieee80211_bss_get_ie", "cfg80211_find_vendor_ie", }; bool is_skb_data(struct expression *expr) Then from there, I actually have an unpublished static checker warning which would have triggered. drivers/net/wireless/microchip/wilc1000/cfg80211.c:991 wilc_wfi_cfg_parse_ch_attr() warn: uncapped user loop: 'attr_size' Currently it prints 178 warnings. It warns for things like: for (i = 0; i < user_controlled_value; i++) But it's kind of useless. There are too many times where the loop is uncapped but it doesn't result in an out of bounds access. For example, the user_controlled_value could be number of seconds instead of array offsets. I need to add to the check and cut down on the false positives. I will do that today. Update on my employment situation: I have been lazy about looking for Smatch funding. But a lot of the things I'm looking at are a subscription model where people get the warnings instead of the source code. These emails are intended to help the Kernel security community to understand better how to continue the work after I have moved on. Please email me if you have questions, because right now I have time and I want to help people take on this work. regards, dan carpenter |
|
Dan Carpenter <error27@...>
It turned out fairly easy to write this check. There are now just 48
warnings so that's not too bad. I'm attaching the list and the code to generate it. I'm trying to involve more people in analyzing Smatch warnings so I'm going to explain how I read these in depth below. This is the most interesting warning. I've added Jason Wang to the CC list because he knows the code better than I would. drivers/net/tap.c:1227 tap_sendmsg() warn: uncapped user loop index 'i' 1216 static int tap_sendmsg(struct socket *sock, struct msghdr *m, 1217 size_t total_len) 1218 { 1219 struct tap_queue *q = container_of(sock, struct tap_queue, sock); 1220 struct tun_msg_ctl *ctl = m->msg_control; 1221 struct xdp_buff *xdp; 1222 int i; 1223 1224 if (m->msg_controllen == sizeof(struct tun_msg_ctl) && 1225 ctl && ctl->type == TUN_MSG_PTR) { 1226 for (i = 0; i < ctl->num; i++) { 1227 xdp = &((struct xdp_buff *)ctl->ptr)[i]; 1228 tap_get_user_xdp(q, xdp); 1229 } 1230 return 0; 1231 } 1232 1233 return tap_get_user(q, ctl ? ctl->ptr : NULL, &m->msg_iter, 1234 m->msg_flags & MSG_DONTWAIT); 1235 } Here Smatch thinks m->msg_control is controlled by the user because of this code from ____sys_sendmsg(): net/socket.c 2479 if (copy_from_user(ctl_buf, msg_sys->msg_control_user, ctl_len)) 2480 goto out_freectl; 2481 msg_sys->msg_control = ctl_buf; ^^^^^^^^^^^^^^^^^^^^ Of course this would be a very serious bug if it's real, but I don't have the expertise to evaluate it properly. drivers/char/agp/generic.c:271 agp_allocate_memory() warn: uncapped user loop index 'i' 248 scratch_pages = (page_count + ENTRIES_PER_PAGE - 1) / ENTRIES_PER_PAGE; 249 250 new = agp_create_memory(scratch_pages); ... 264 for (i = 0; i < page_count; i++) { ... 271 new->pages[i] = page; In this code, we allocate "scratch_pages" number of pages. Smatch does not understand that properly track the relationship between page_count and scratch_pages or the relationship between scratch_pages and new->pages. Two things which should be fixed. drivers/dma/qcom/hidma_mgmt.c:101 hidma_mgmt_setup() warn: uncapped user loop index 'i' This is the first real bug, but it's root only so it's not a security issue. I have reported it. drivers/comedi/comedi_fops.c:1445 parse_insn() warn: uncapped user loop index 'i' If you look at do_insn_ioctl() the size of the "data" array is "n_data" and "n_data" is more than "insn->n". Smatch tries to track when a variable *is* the array size, but I don't think we will track that the ariable is less than the array size across function boundaries. drivers/net/can/sun4i_can.c:458 sun4ican_start_xmit() warn: uncapped user loop index 'i' CAN is problematic for Smatch because when it recieves a packet it take skb->data (which is a buffer of u8) and then checks it and then stuffs it back into the buffer of u8. When the buffer gets stuffed back into skb->data then the details about how it was checked are lost. Probably it's safe to ignore all 8 drivers/net/can/ warnings. drivers/net/wireless/ath/ath10k/htt_rx.c:2988 ath10k_htt_rx_tx_compl_ind() warn: uncapped user loop index 'i' Smatch assumes that every skb->data holds untrusted data. One place where this assumption fails is on the sending path. I notice that this function has both RX and TX in the name, so it might be a send path. I do not know if this is a real bug or not. drivers/net/wireless/ath/ath6kl/wmi.c:1304 ath6kl_wmi_neighbor_report_event_rx() warn: uncapped user loop index 'i' 1287 static int ath6kl_wmi_neighbor_report_event_rx(struct wmi *wmi, u8 *datap, 1288 int len, struct ath6kl_vif *vif) 1289 { 1290 struct wmi_neighbor_report_event *ev; 1291 u8 i; 1292 1293 if (len < sizeof(*ev)) 1294 return -EINVAL; 1295 ev = (struct wmi_neighbor_report_event *) datap; 1296 if (struct_size(ev, neighbor, ev->num_neighbors) > len) { ^^^^^^^^^^^^^^^^^ Smatch needs to be fixed to recognize that "ev->num_neighbors" is checked here. Fixable. 1297 ath6kl_dbg(ATH6KL_DBG_WMI, 1298 "truncated neighbor event (num=%d len=%d)\n", 1299 ev->num_neighbors, len); 1300 return -EINVAL; 1301 } 1302 for (i = 0; i < ev->num_neighbors; i++) { 1303 ath6kl_dbg(ATH6KL_DBG_WMI, "neighbor %d/%d - %pM 0x%x\n", 1304 i + 1, ev->num_neighbors, ev->neighbor[i].bssid, 1305 ev->neighbor[i].bss_flags); 1306 cfg80211_pmksa_candidate_notify(vif->ndev, i, 1307 ev->neighbor[i].bssid, 1308 !!(ev->neighbor[i].bss_flags & 1309 WMI_PREAUTH_CAPABLE_BSS), 1310 GFP_ATOMIC); 1311 } 1312 1313 return 0; 1314 } drivers/net/wireless/quantenna/qtnfmac/commands.c:1100 qtnf_parse_variable_mac_info() warn: uncapped user loop index 'i' 1079 rec_len = sizeof(*rec) + rec->n_limits * sizeof(*lim); 1080 1081 if (unlikely(tlv_value_len != rec_len)) { Another false positive. This bounds checking on "rec->n_limits" was too complicated for Smatch. drivers/net/ethernet/mediatek/mtk_wed_mcu.c:82 mtk_wed_update_rx_stats() warn: uncapped user loop index 'i' 64 static void 65 mtk_wed_update_rx_stats(struct mtk_wed_device *wed, struct sk_buff *skb) 66 { 67 u32 count = get_unaligned_le32(skb->data); 68 struct mtk_wed_wo_rx_stats *stats; 69 int i; 70 71 if (count * sizeof(*stats) > skb->len - sizeof(u32)) 72 return; 73 74 stats = (struct mtk_wed_wo_rx_stats *)(skb->data + sizeof(u32)); 75 for (i = 0 ; i < count ; i++) 76 wed->wlan.update_wo_rx_stats(wed, &stats[i]); 77 } The bounds checking is too complicated for Smatch, but also this code is buggy. Bug 1: There is no check to ensure that skb->len >= sizeof(u32). Bug 2: On a 32 bit system the "count * sizeof(*stats)" multiplication can lead to an integer overflow. I have reported these bugs. regards, dan carpenter |
|
Masami Ichikawa
Hi !
It's this week's CVE report. This week reported 4 new CVEs and 3 updated CVEs. * New CVEs CVE-2023-0469: A use-after-free flaw was found in io_uring/filetable.c CVSS v3 score is not provided A use-after-free flaw was found in io_uring/filetable.c in io_install_fixed_file in the io_uring subcomponent in the Linux Kernel during call cleanup. This flaw may lead to a denial of service. This bug was introduced by commit 61c1b44 ("io_uring: fix deadlock on iowq file slot alloc") in 5.19-rc1. It fixes 1339f24 ("io_uring: allow allocated fixed files for openat/openat2") in 510-rc1. This bug was fixed by commit 9d94c04 ("io_uring/filetable: fix file reference underflow") in 6.1-rc7. The commit 1339f24 is not backported to older stable kernels. Fixed status mainline: [9d94c04c0db024922e886c9fd429659f22f48ea4] CVE-2023-0240: Privilege escalation bug in io_uring CVSS v3 score is not provided (NIST) CVSS v3 score is 7.8 HIGH (CNA) There is a logic error in io_uring's implementation which can be used to trigger a use-after-free vulnerability leading to privilege escalation. In the io_prep_async_work function the assumption that the last io_grab_identity call cannot return false is not true, and in this case the function will use the init_cred or the previous linked requests identity to do operations instead of using the current identity. This can lead to reference counting issues causing use-after-free. It looks only affects 5.10. Fixed status mainline: [4379bf8bd70b5de6bba7d53015b0c36c57a634ee] stable/5.10: [788d0824269bef539fe31a785b1517882eafed93] CVE-2023-0590: net: sched: fix race condition in qdisc_graft() CVSS v3 score is not provided. A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem leading to a denial-of-service problem. It was introduced by commit af356af ("net_sched: reintroduce dev->qdisc for use by sch_api") in 2.6.32-rc1 and fixed in 6.1-rc2. Fixed status mainline: [ebda44da44f6f309d302522b049f43d6f829f7aa] stable/5.10: [7aa3d623c11b9ab60f86b7833666e5d55bac4be9] stable/5.15: [ce1234573d183db1ebcab524668ca2d85543bf80] CVE-2023-0597: kernel: x86/mm: Randomize per-cpu entry area CVSS v3 score is not provided. A new Side-Channel Attacks was found in prefetch instructions. It an unprivileged attacker to obtain address information. This details is published in the paper called "Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR" (https://gruss.cc/files/prefetch.pdf) Fixed status mainline: [97e3d26b5e5f371b3ee223d94dd123e6c442ba80] * Updated CVEs CVE-2023-23559: rndis_wlan: Prevent buffer overflow in rndis_query_oid mainline, 5.10, 5.15, and 6.1 were fixed. Fixed status mainline: [b870e73a56c4cccbec33224233eaf295839f228c] stable/5.10: [802fd7623e9ed19ee809b503e93fccc1e3f37bd6] stable/5.15: [8cbf932c5c40b0c20597fa623c308d5bde0848b5] stable/6.1: [7794efa358bca8b8a2a80070c6e088a74945f018] CVE-2022-4129: l2tp: missing lock when clearing sk_user_data can lead to NULL pointer dereference stable 5.10 and 5.15 were fixed. Fixed status mainline: [b68777d54fac21fc833ec26ea1a2a84f975ab035, af295e854a4e3813ffbdef26dbb6a4d6226c3ea1] stable/5.10: [e34a965f771f1977f172593c73e373036c765724, 5b209b8c99d487a1c32983981bf3552980fda591] stable/5.15: [87d9205d9a57dfc1f39f840b32e38475c3f523f6, 22c7d45ca3d7672f0b209783726d7559a2343f21] CVE-2022-4382: usb: A use-after-free Write in put_dev mainline, 5.10, 5.15, 5.4, and 6.1 were fixed. This vulnerability was introduced by commit e5d82a7360d1 ("vfs: Convert gadgetfs to use the new mount API") in 5.3-r1 so 4.x are not affected. Fixed status mainline: [d18dcfe9860e842f394e37ba01ca9440ab2178f4] stable/5.10: [856e4b5e53f21edbd15d275dde62228dd94fb2b4] stable/5.15: [a2e075f40122d8daf587db126c562a67abd69cf9] stable/5.4: [9a39f4626b361ee7aa10fd990401c37ec3b466ae] stable/6.1: [616fd34d017000ecf9097368b13d8a266f4920b3] 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-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@... :masami.ichikawa@... |
|