CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47591 – mptcp: remove tcp ulp setsockopt support
https://notcve.org/view.php?id=CVE-2021-47591
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: mptcp: remove tcp ulp setsockopt support TCP_ULP setsockopt cannot be used for mptcp because its already used internally to plumb subflow (tcp) sockets to the mptcp layer. syzbot managed to trigger a crash for mptcp connections that are in fallback mode: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c... • https://git.kernel.org/stable/c/d9e4c129181004ec94b315b0c9db5eeb09da75e6 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47590 – mptcp: fix deadlock in __mptcp_push_pending()
https://notcve.org/view.php?id=CVE-2021-47590
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: mptcp: fix deadlock in __mptcp_push_pending() __mptcp_push_pending() may call mptcp_flush_join_list() with subflow socket lock held. If such call hits mptcp_sockopt_sync_all() then subsequently __mptcp_sockopt_sync() could try to lock the subflow socket for itself, causing a deadlock. sysrq: Show Blocked State task:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000 Call Trace:
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47589 – igbvf: fix double free in `igbvf_probe`
https://notcve.org/view.php?id=CVE-2021-47589
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: igbvf: fix double free in `igbvf_probe` In `igbvf_probe`, if register_netdev() fails, the program will go to label err_hw_init, and then to label err_ioremap. In free_netdev() which is just below label err_ioremap, there is `list_for_each_entry_safe` and `netif_napi_del` which aims to delete all entries in `dev->napi_list`. The program has added an entry `adapter->rx_ring->napi` which is added by `netif_napi_add` in igbvf_alloc_queues(). Ho... • https://git.kernel.org/stable/c/d4e0fe01a38a073568aee541a0247fe734095979 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47588 – sit: do not call ipip6_dev_free() from sit_init_net()
https://notcve.org/view.php?id=CVE-2021-47588
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: sit: do not call ipip6_dev_free() from sit_init_net() ipip6_dev_free is sit dev->priv_destructor, already called by register_netdevice() if something goes wrong. Alternative would be to make ipip6_dev_free() robust against multiple invocations, but other drivers do not implement this strategy. syzbot reported: dst_release underflow WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Modules linked in: CP... • https://git.kernel.org/stable/c/cf124db566e6b036b8bcbe8decbed740bdfac8c6 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47587 – net: systemport: Add global locking for descriptor lifecycle
https://notcve.org/view.php?id=CVE-2021-47587
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: net: systemport: Add global locking for descriptor lifecycle The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit que... • https://git.kernel.org/stable/c/80105befdb4b8cea924711b40b2462b87df65b62 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47586 – net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup
https://notcve.org/view.php?id=CVE-2021-47586
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup KASAN reports an out-of-bounds read in rk_gmac_setup on the line: while (ops->regs[i]) { This happens for most platforms since the regs flexible array member is empty, so the memory after the ops structure is being read here. It seems that mostly this happens to contain zero anyway, so we get lucky and everything still works. To avoid adding redundant data to nearly all the ops structures... • https://git.kernel.org/stable/c/3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47585 – btrfs: fix memory leak in __add_inode_ref()
https://notcve.org/view.php?id=CVE-2021-47585
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in __add_inode_ref() Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(), but when the function returns in line 1184 (#4) victim_name allocated by line 1169 (#3) is not freed, which will lead to a memory leak. There is a similar snippet of code in this function as allocating a memory chunk for victim_name in line 1104 (#1) as well as releasing the memory in line 1116 (#2). We should kfree() victim_nam... • https://git.kernel.org/stable/c/d3316c8233bb05e0dd855d30aac347bb8ad76ee4 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47584 – iocost: Fix divide-by-zero on donation from low hweight cgroup
https://notcve.org/view.php?id=CVE-2021-47584
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: iocost: Fix divide-by-zero on donation from low hweight cgroup The donation calculation logic assumes that the donor has non-zero after-donation hweight, so the lowest active hweight a donating cgroup can have is 2 so that it can donate 1 while keeping the other 1 for itself. Earlier, we only donated from cgroups with sizable surpluses so this condition was always true. However, with the precise donation algorithm implemented, f1de2439ec43 ... • https://git.kernel.org/stable/c/f1de2439ec43b74764f2a26e3a310b24407e3bde •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47583 – media: mxl111sf: change mutex_init() location
https://notcve.org/view.php?id=CVE-2021-47583
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: media: mxl111sf: change mutex_init() location Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location. Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Since mxl111sf_* devices call mxl111sf_ctrl_msg() in... • https://git.kernel.org/stable/c/8572211842afc53c8450fb470f2b8d02ba7592e0 •
CVSS: 4.6EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47582 – USB: core: Make do_proc_control() and do_proc_bulk() killable
https://notcve.org/view.php?id=CVE-2021-47582
19 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: USB: core: Make do_proc_control() and do_proc_bulk() killable The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot: INFO: task syz-ex... • https://git.kernel.org/stable/c/403716741c6c2c510dce44e88f085a740f535de6 • CWE-667: Improper Locking •