CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47283 – net:sfc: fix non-freed irq in legacy irq mode
https://notcve.org/view.php?id=CVE-2021-47283
In the Linux kernel, the following vulnerability has been resolved: net:sfc: fix non-freed irq in legacy irq mode SFC driver can be configured via modparam to work using MSI-X, MSI or legacy IRQ interrupts. In the last one, the interrupt was not properly released on module remove. It was not freed because the flag irqs_hooked was not set during initialization in the case of using legacy IRQ. Example of (trimmed) trace during module remove without this fix: remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1' WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170 ...trimmed... Call Trace: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device+0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0+0x171/0x280 ? exit_to_user_mode_prepare+0x83/0x1d0 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9f9385800b ...trimmed... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net:sfc: corrige irq no liberado en modo irq heredado. El controlador SFC se puede configurar mediante modparam para que funcione usando interrupciones MSI-X, MSI o IRQ heredadas. • https://git.kernel.org/stable/c/8d717c9135a3340ae62d1699484850bfb4112b0c https://git.kernel.org/stable/c/81c4d1d83f88e15b26f4522a35cba6ffd8c5dfdd https://git.kernel.org/stable/c/8f03eeb6e0a0a0b8d617ee0a4bce729e47130036 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47281 – ALSA: seq: Fix race of snd_seq_timer_open()
https://notcve.org/view.php?id=CVE-2021-47281
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix race of snd_seq_timer_open() The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently. For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix race of snd_seq_timer_open(). La instancia del temporizador por cola es exclusiva, y snd_seq_timer_open() debería haber gestionado los accesos concurrentes. • https://git.kernel.org/stable/c/bd7d88b0874f82f7b29d1a53e574cedaf23166ba https://git.kernel.org/stable/c/536a7646c00a0f14fee49e5e313109e5da2f6031 https://git.kernel.org/stable/c/83e197a8414c0ba545e7e3916ce05f836f349273 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47280 – drm: Fix use-after-free read in drm_getunique()
https://notcve.org/view.php?id=CVE-2021-47280
In the Linux kernel, the following vulnerability has been resolved: drm: Fix use-after-free read in drm_getunique() There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report of the use-after-free error found by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master pointer was used after being freed. This is because another process had acquired the device's master mutex in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot reproducer test. • https://git.kernel.org/stable/c/17dab9326ff263c62dab1dbac4492e2938a049e4 https://git.kernel.org/stable/c/7d233ba700ceb593905ea82b42dadb4ec8ef85e9 https://git.kernel.org/stable/c/b246b4c70c1250e7814f409b243000f9c0bf79a3 https://git.kernel.org/stable/c/491d52e0078860b33b6c14f0a7ac74ca1b603bd6 https://git.kernel.org/stable/c/f773f8cccac13c7e7bbd9182e7996c727742488e https://git.kernel.org/stable/c/b436acd1cf7fac0ba987abd22955d98025c80c2b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47277 – kvm: avoid speculation-based attacks from out-of-range memslot accesses
https://notcve.org/view.php?id=CVE-2021-47277
In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. • https://git.kernel.org/stable/c/3098b86390a6b9ea52657689f08410baf130ceff https://git.kernel.org/stable/c/740621309b25bbf619b8a0ba5fd50a8e58989441 https://git.kernel.org/stable/c/361ce3b917aff93123e9e966d8608655c967f438 https://git.kernel.org/stable/c/22b87fb17a28d37331bb9c1110737627b17f6781 https://git.kernel.org/stable/c/bff1fbf0cf0712686f1df59a83fba6e31d2746a0 https://git.kernel.org/stable/c/7af299b97734c7e7f465b42a2139ce4d77246975 https://git.kernel.org/stable/c/ed0e2a893092c7fcb4ff7ba74e5efce53a6f5940 https://git.kernel.org/stable/c/da27a83fd6cc7780fea190e1f5c19e870 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47275 – bcache: avoid oversized read request in cache missing code path
https://notcve.org/view.php?id=CVE-2021-47275
In the Linux kernel, the following vulnerability has been resolved: bcache: avoid oversized read request in cache missing code path In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. • https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478 •