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 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
This 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@...