CVE-2021-47570 – staging: r8188eu: fix a memory leak in rtw_wx_read32()
https://notcve.org/view.php?id=CVE-2021-47570
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: staging: r8188eu: fix a memory leak in rtw_wx_read32() Free "ptmp" before returning -EINVAL. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: staging: r8188eu: soluciona una pérdida de memoria en rtw_wx_read32() Libera "ptmp" antes de devolver -EINVAL. • https://git.kernel.org/stable/c/2b42bd58b32155a1be4dd78991845dec05aaef9e • CWE-401: Missing Release of Memory after Effective Lifetime •
CVE-2021-47569 – io_uring: fail cancellation for EXITING tasks
https://notcve.org/view.php?id=CVE-2021-47569
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: io_uring: fail cancellation for EXITING tasks WARNING: CPU: 1 PID: 20 at fs/io_uring.c:6269 io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269 CPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0 Workqueue: events io_fallback_req_func RIP: 0010:io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269 Call Trace:
CVE-2021-47568 – ksmbd: fix memleak in get_file_stream_info()
https://notcve.org/view.php?id=CVE-2021-47568
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memleak in get_file_stream_info() Fix memleak in get_file_stream_info() En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige memleak en get_file_stream_info() Corrige memleak en get_file_stream_info() • https://git.kernel.org/stable/c/34061d6b76a41b1e43c19e1e50d98e5d77f77d4e •
CVE-2021-47567 – powerpc/32: Fix hardlockup on vmap stack overflow
https://notcve.org/view.php?id=CVE-2021-47567
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: powerpc/32: Fix hardlockup on vmap stack overflow Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") a vmap stack overflow results in a hard lockup. This is because emergency_ctx is still addressed with its virtual address allthough data MMU is not active anymore at that time. Fix it by using a physical address instead. En el kernel de Linux, se ha resuelto la siguiente vulnerabilid... • https://git.kernel.org/stable/c/c118c7303ad528be8ff2aea8cd1ee15452c763f0 •
CVE-2021-47566 – proc/vmcore: fix clearing user buffer by properly using clear_user()
https://notcve.org/view.php?id=CVE-2021-47566
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdum... • https://git.kernel.org/stable/c/997c136f518c5debd63847e78e2a8694f56dcf90 • CWE-501: Trust Boundary Violation •
CVE-2021-47565 – scsi: mpt3sas: Fix kernel panic during drive powercycle test
https://notcve.org/view.php?id=CVE-2021-47565
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. En el kernel de Linux, se resolvió la siguien... • https://git.kernel.org/stable/c/f92363d12359498f9a9960511de1a550f0ec41c2 •
CVE-2021-47564 – net: marvell: prestera: fix double free issue on err path
https://notcve.org/view.php?id=CVE-2021-47564
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix double free issue on err path fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bri... • https://git.kernel.org/stable/c/e1189d9a5fbec8153dbe03f3589bc2baa96694e2 •
CVE-2021-47563 – ice: avoid bpf_prog refcount underflow
https://notcve.org/view.php?id=CVE-2021-47563
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_v... • https://git.kernel.org/stable/c/efc2214b6047b6f5b4ca53151eba62521b9452d6 •
CVE-2021-47562 – ice: fix vsi->txq_map sizing
https://notcve.org/view.php?id=CVE-2021-47562
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ice: fix vsi->txq_map sizing The approach of having XDP queue per CPU regardless of user's setting exposed a hidden bug that could occur in case when Rx queue count differ from Tx queue count. Currently vsi->txq_map's size is equal to the doubled vsi->alloc_txq, which is not correct due to the fact that XDP rings were previously based on the Rx queue count. Below splat can be seen when ethtool -L is used and XDP rings are configured: [ 682.... • https://git.kernel.org/stable/c/efc2214b6047b6f5b4ca53151eba62521b9452d6 •
CVE-2021-47561 – i2c: virtio: disable timeout handling
https://notcve.org/view.php?id=CVE-2021-47561
24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: disable timeout handling If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device):... • https://git.kernel.org/stable/c/3cfc88380413d20f777dc6648a38f683962e52bf •