CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47218 – selinux: fix NULL-pointer dereference when hashtab allocation fails
https://notcve.org/view.php?id=CVE-2021-47218
In the Linux kernel, the following vulnerability has been resolved: selinux: fix NULL-pointer dereference when hashtab allocation fails When the hash table slot array allocation fails in hashtab_init(), h->size is left initialized with a non-zero value, but the h->htable pointer is NULL. This may then cause a NULL pointer dereference, since the policydb code relies on the assumption that even after a failed hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called on it. Yet, these detect an empty hashtab only by looking at the size. Fix this by making sure that hashtab_init() always leaves behind a valid empty hashtab when the allocation fails. • https://git.kernel.org/stable/c/03414a49ad5f3c56988c36d2070e402ffa17feaf https://git.kernel.org/stable/c/b17dd53cac769dd13031b0ca34f90cc65e523fab https://git.kernel.org/stable/c/83c8ab8503adf56bf68dafc7a382f4946c87da79 https://git.kernel.org/stable/c/dc27f3c5d10c58069672215787a96b4fae01818b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47217 – x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
https://notcve.org/view.php?id=CVE-2021-47217
In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30 • https://git.kernel.org/stable/c/93286261de1b46339aa27cd4c639b21778f6cade https://git.kernel.org/stable/c/b20ec58f8a6f4fef32cc71480ddf824584e24743 https://git.kernel.org/stable/c/b0e44dfb4e4c699cca33ede431b8d127e6e8d661 https://git.kernel.org/stable/c/9c177eee116cf888276d3748cb176e72562cfd5c https://git.kernel.org/stable/c/8823ea27fff6084bbb4bc71d15378fae0220b1d8 https://git.kernel.org/stable/c/daf972118c517b91f74ff1731417feb4270625a4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47216 – scsi: advansys: Fix kernel pointer leak
https://notcve.org/view.php?id=CVE-2021-47216
In the Linux kernel, the following vulnerability has been resolved: scsi: advansys: Fix kernel pointer leak Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx. Change %lx to %p to print the hashed pointer. • https://git.kernel.org/stable/c/06d7d12efb5c62db9dea15141ae2b322c2719515 https://git.kernel.org/stable/c/ad19f7046c24f95c674fbea21870479b2b9f5bab https://git.kernel.org/stable/c/5612287991debe310c914600599bd59511ababfb https://git.kernel.org/stable/c/f5a0ba4a9b5e70e7b2f767636d26523f9d1ac59d https://git.kernel.org/stable/c/cc248790bfdcf879e3094fa248c85bf92cdf9dae https://git.kernel.org/stable/c/055eced3edf5b675d12189081303f6285ef26511 https://git.kernel.org/stable/c/27490ae6a85a70242d80615ca74d0362a820d6a7 https://git.kernel.org/stable/c/d4996c6eac4c81b8872043e9391563f67 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47215 – net/mlx5e: kTLS, Fix crash in RX resync flow
https://notcve.org/view.php?id=CVE-2021-47215
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix crash in RX resync flow For the TLS RX resync flow, we maintain a list of TLS contexts that require some attention, to communicate their resync information to the HW. Here we fix list corruptions, by protecting the entries against movements coming from resync_handle_seq_match(), until their resync handling in napi is fully completed. • https://git.kernel.org/stable/c/e9ce991bce5bacf71641bd0f72f4b7c589529f40 https://git.kernel.org/stable/c/ebeda7a9528ae690e6bf12791a868f0cca8391f2 https://git.kernel.org/stable/c/cc4a9cc03faa6d8db1a6954bb536f2c1e63bdff6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47214 – hugetlb, userfaultfd: fix reservation restore on userfaultfd error
https://notcve.org/view.php?id=CVE-2021-47214
In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using "goto out_release_unlock;" in the cases where idx >= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h->resv_hugepages causing a 100% reproducible leak. We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear. • https://git.kernel.org/stable/c/c7b1850dfb41d0b4154aca8dbc04777fbd75616f https://git.kernel.org/stable/c/515b6124df6a84c957c5cc6bb6e8309dae7b1e9c https://git.kernel.org/stable/c/b5069d44e2fbc4a9093d005b3ef0949add3dd27e https://git.kernel.org/stable/c/cc30042df6fcc82ea18acf0dace831503e60a0b7 •