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: 8EXPL: 0CVE-2021-47276 – ftrace: Do not blindly read the ip address in ftrace_bug()
https://notcve.org/view.php?id=CVE-2021-47276
In the Linux kernel, the following vulnerability has been resolved: ftrace: Do not blindly read the ip address in ftrace_bug() It was reported that a bug on arm64 caused a bad ip address to be used for updating into a nop in ftrace_init(), but the error path (rightfully) returned -EINVAL and not -EFAULT, as the bug caused more than one error to occur. But because -EINVAL was returned, the ftrace_bug() tried to report what was at the location of the ip address, and read it directly. This caused the machine to panic, as the ip was not pointing to a valid memory address. Instead, read the ip address with copy_from_kernel_nofault() to safely access the memory, and if it faults, report that the address faulted, otherwise report what was in that location. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ftrace: no lea ciegamente la dirección IP en ftrace_bug(). Se informó que un error en arm64 provocó que se usara una dirección IP incorrecta para actualizar a un nop en ftrace_init() , pero la ruta de error (con razón) devolvió -EINVAL y no -EFAULT, ya que el error provocó que ocurriera más de un error. • https://git.kernel.org/stable/c/05736a427f7e16be948ccbf39782bd3a6ae16b14 https://git.kernel.org/stable/c/0bc62e398bbd9e600959e610def5109957437b28 https://git.kernel.org/stable/c/4aedc2bc2b32c93555f47c95610efb89cc1ec09b https://git.kernel.org/stable/c/acf671ba79c1feccc3ec7cfdcffead4efcec49e7 https://git.kernel.org/stable/c/862dcc14f2803c556bdd73b43c27b023fafce2fb https://git.kernel.org/stable/c/7e4e824b109f1d41ccf223fbb0565d877d6223a2 https://git.kernel.org/stable/c/97524384762c1fb9b3ded931498dd2047bd0de81 https://git.kernel.org/stable/c/3e4ddeb68751fb4fb657199aed9cfd5d0 •
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47270 – usb: fix various gadgets null ptr deref on 10gbps cabling.
https://notcve.org/view.php?id=CVE-2021-47270
In the Linux kernel, the following vulnerability has been resolved: usb: fix various gadgets null ptr deref on 10gbps cabling. This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: repara varios gadgets null ptr deref en cableado de 10gbps. Esto evita una desreferencia de puntero null en f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} simplemente reutilizando la configuración de 5 gbps para 10 gbps. • https://git.kernel.org/stable/c/eaef50c760576bca70b87fdc26eb87a3660529f8 https://git.kernel.org/stable/c/beb1e67a5ca8d69703c776db9000527f44c0c93c https://git.kernel.org/stable/c/8cd5f45c1b769e3e9e0f4325dd08b6c3749dc7ee https://git.kernel.org/stable/c/10770d2ac0094b053c8897d96d7b2737cd72f7c5 https://git.kernel.org/stable/c/b4903f7fdc484628d0b8022daf86e2439d3ab4db https://git.kernel.org/stable/c/4b289a0f3033f465b4fd51ba995251a7867a2aa2 https://git.kernel.org/stable/c/f17aae7c4009160f0630a91842a281773976a5bc https://git.kernel.org/stable/c/90c4d05780d47e14a50e11a7f17373104 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47269 – usb: dwc3: ep0: fix NULL pointer exception
https://notcve.org/view.php?id=CVE-2021-47269
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: ep0: fix NULL pointer exception There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing. By adding this validation from the patch we can actually report a wrong index back to the caller. In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation. [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepción de puntero NULL. No hay validación del índice desde dwc3_wIndex_to_dep() y podríamos estar haciendo referencia a un ep inexistente y desencadenar una excepción de puntero NULL. En ciertas configuraciones, podríamos usar menos eps y el índice podría indicar erróneamente un índice ep mayor que el existente. • https://git.kernel.org/stable/c/96b74a99d360235c24052f1d060e64ac53f43528 https://git.kernel.org/stable/c/60156089f07e724e4dc8483702d5e1ede4522749 https://git.kernel.org/stable/c/990dc90750772622d44ca2ea6652c521e6f67e16 https://git.kernel.org/stable/c/bd551e7c85939de2182010273450bfa78c3742fc https://git.kernel.org/stable/c/366369b89bedd59b1425386e8d4a18a466e420e4 https://git.kernel.org/stable/c/470403639114895e2697c766fbe17be8d0e9b67a https://git.kernel.org/stable/c/788755756dd4a6aba1de479fec20b0fa600e7f19 https://git.kernel.org/stable/c/d00889080ab60051627dab1d85831cd9d •