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: 9.8EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47274 – tracing: Correct the length check which causes memory corruption
https://notcve.org/view.php?id=CVE-2021-47274
In the Linux kernel, the following vulnerability has been resolved: tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rastreo: corrija la verificación de longitud que causa corrupción de la memoria. Hemos sufrido fallos graves del kernel debido a la corrupción de la memoria en nuestro entorno de producción, como Call Trace: [1640542.554277] fallo de protección general. : 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: cargado Contaminado:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] : 0018:ffffb16faa597df8 EFLAGS: 00010286 [ 1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] : 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) GS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.5 66069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Seguimiento de llamadas: [1640542.567009] anon_vma_clone+0x5d/0x170 2.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] _64+0x5b/0x1b0 [1640542.573724] entrada_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang lo ha reproducido de forma estable en la última versión 4.19 LTS. Después de algunas depuraciones, finalmente demostramos que se debe al acceso fuera de los límites al búfer ftrace usando una herramienta de depuración de la siguiente manera: [86.775200] ERROR: Escritura fuera de los límites en la dirección 0xffff88aefe8b7000 [86.780806] no_context+0xdf/0x3c0 [86.784327 ] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] ry_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func +0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] ffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900 ] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("rastreo: verificar la longitud antes de entregar el búfer de filtro") agrega verificación de longitud para proteger el desbordamiento de datos de seguimiento introducido en 0fc1b09ff1ff, parece que esta solución no puede evitar el desbordamiento por completo, la verificación de longitud también debería tenga en cuenta el tamaño de la entrada->matriz[0], ya que esta matriz[0] ocupa toda la longitud de los datos de seguimiento y ocupa espacio adicional y corre el riesgo de desbordarse. • https://git.kernel.org/stable/c/2e584b1a02eeb860e286d39bc408b25ebc5ec844 https://git.kernel.org/stable/c/e46d433754420b4d6513ca389403de88a0910279 https://git.kernel.org/stable/c/0572fc6a510add9029b113239eaabf4b5bce8ec9 https://git.kernel.org/stable/c/a0997a86f5c0085e183ddee5fb72091d584d3d16 https://git.kernel.org/stable/c/7c93d8cff582c459350d6f8906eea6e4cd60d959 https://git.kernel.org/stable/c/b220c049d5196dd94d992dd2dc8cba1a5e6123bf https://git.kernel.org/stable/c/edcce01e0e50840a9aa6a70baed21477bdd2c9f9 https://git.kernel.org/stable/c/2d598902799886d67947406f26ee8e5fd • CWE-125: Out-of-bounds Read •
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47267 – usb: fix various gadget panics on 10gbps cabling
https://notcve.org/view.php?id=CVE-2021-47267
In the Linux kernel, the following vulnerability has been resolved: usb: fix various gadget panics on 10gbps cabling usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: corrige varios fallos de dispositivos en cableado de 10 gbps usb_assign_descriptors() se llama con 5 parámetros, los últimos 4 de los cuales son usb_descriptor_header para: velocidad completa (USB1.1 - 12Mbps [ incluyendo USB1.0 de baja velocidad a 1,5 Mbps), alta velocidad (USB2.0 - 480 Mbps), súper velocidad (USB3.0 - 5 Gbps), súper velocidad plus (USB3.1 - 10 Gbps). Las diferencias entre los descriptores de velocidad completa/alta/supervelocidad suelen ser sustanciales (debido a cambios en el tamaño máximo del bloque USB de 64 a 512 a 1024 bytes y otras diferencias en las especificaciones), mientras que la diferencia entre los descriptores de 5 y 10 Gbps puede ser tan casi nada (en muchos casos, la misma afinación es simplemente suficiente). Sin embargo, si un controlador de dispositivo llama a usb_assign_descriptors() con un descriptor NULL para super-speed-plus y luego se usa en una configuración máxima de 10 gbps, el kernel fallará con una desreferencia de puntero null, cuando un puerto de dispositivo con capacidad de 10 gbps + cable + puerto de host Aparece la combinación. (Esto no sucedería si la velocidad máxima del dispositivo estuviera configurada en 5 gbps, pero, por supuesto, está predeterminada al máximo y no hay ninguna razón real para limitarla artificialmente). • https://git.kernel.org/stable/c/fd24be23abf3e94260be0f00bb42c7e91d495f87 https://git.kernel.org/stable/c/70cd19cb5bd94bbb5bacfc9c1e4ee0071699a604 https://git.kernel.org/stable/c/45f9a2fe737dc0a5df270787f2231aee8985cd59 https://git.kernel.org/stable/c/5ef23506695b01d5d56a13a092a97f2478069d75 https://git.kernel.org/stable/c/b972eff874637402ddc4a7dd11fb22538a0b6d28 https://git.kernel.org/stable/c/ca6bc277430d90375452b60b047763a090b7673e https://git.kernel.org/stable/c/032e288097a553db5653af552dd8035cd2a0ba96 •