CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2021-46950 – md/raid1: properly indicate failure when ending a failed write request
https://notcve.org/view.php?id=CVE-2021-46950
In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid1: indica correctamente el error al finalizar una solicitud de escritura fallida. Este parche soluciona un error de corrupción de datos en matrices raid1 que utilizan mapas de bits. Sin esta solución, los bits del mapa de bits de la E/S fallida terminan borrándose. Dado que estamos en el tramo fallido de raid1_end_write_request, es necesario volver a intentar la solicitud (R1BIO_WriteError) o fallar (R1BIO_Degraded). • https://git.kernel.org/stable/c/900c531899f5ee2321bef79e20055787bc73251d https://git.kernel.org/stable/c/1cd972e0a10760a1fa27d9830d78446c891c23b6 https://git.kernel.org/stable/c/eeba6809d8d58908b5ed1b5ceb5fcb09a98a7cad https://git.kernel.org/stable/c/a1f4fcb880988a96c0b2d5c3305ffc4e49eca0ed https://git.kernel.org/stable/c/344242d50f468a250bf4b6136934392758412ed8 https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5 https://git.kernel.org/stable/c/a6e17cab00fc5bf85472434c52ac751426257c6f https://git.kernel.org/stable/c/6920cef604fa57f9409e3960413e9cc11 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46949 – sfc: farch: fix TX queue lookup in TX flush done handling
https://notcve.org/view.php?id=CVE-2021-46949
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de la cola TX en el manejo finalizado del vaciado TX. Estamos comenzando desde un número de instancia TXQ ('qid'), no un tipo TXQ, por lo que efx_get_tx_queue() es inapropiado (y podría devolver NULL, lo que provocaría pánico). • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170 https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647 https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46948 – sfc: farch: fix TX queue lookup in TX event handling
https://notcve.org/view.php?id=CVE-2021-46948
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de cola TX en el manejo de eventos TX Estamos comenzando desde una etiqueta TXQ, no un tipo TXQ, por lo que efx_channel_get_tx_queue() es inapropiado (y podría devolver NULL, provocando pánico). • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253 https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052 https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46947 – sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues
https://notcve.org/view.php?id=CVE-2021-46947
In the Linux kernel, the following vulnerability has been resolved: sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running "# ethtool -S <iface>", similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: <redacted> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: ajuste efx->xdp_tx_queue_count con el número real de colas inicializadas. efx->xdp_tx_queue_count se inicializa inicialmente en num_possible_cpus() y luego se usa para asignar y recorrer la búsqueda de efx->xdp_tx_queues formación. Sin embargo, es posible que terminemos sin inicializar todas las ranuras de la matriz con colas reales durante el sondeo. • https://git.kernel.org/stable/c/e26ca4b535820b1445dcef3c0f82b3fb5b45108b https://git.kernel.org/stable/c/ebeac958b690123a0b40aa61f688f2f170035fad https://git.kernel.org/stable/c/99ba0ea616aabdc8e26259fd722503e012199a76 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46945 – ext4: always panic when errors=panic is specified
https://notcve.org/view.php?id=CVE-2021-46945
In the Linux kernel, the following vulnerability has been resolved: ext4: always panic when errors=panic is specified Before commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option "abort" will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel's behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option "abort".) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4's behaviour much more consistent, so this is a good thing. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: siempre entra en pánico cuando se especifica errores=panic Antes del commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), la siguiente serie de comandos desencadenaría un pánico: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test Después de el commit 014c9caa29d3, volver a montar un sistema de archivos utilizando la opción de montaje de prueba "abort" ya no provocará pánico . Esta confirmación restaurará el comportamiento inmediatamente anterior a el commit 014c9caa29d3. (Sin embargo, tenga en cuenta que el comportamiento del kernel de Linux no ha sido consistente; algunas versiones anteriores del kernel, incluidas 5.4 y 4.19, tampoco entraron en pánico después de usar la opción de montaje "abortar".) • https://git.kernel.org/stable/c/014c9caa29d3a44e0de695c99ef18bec3e887d52 https://git.kernel.org/stable/c/64e1eebe2131183174f4fbb6b1491355f96c6cde https://git.kernel.org/stable/c/1e9ea8f4637026b8e965128953f2da061ccae9c4 https://git.kernel.org/stable/c/ac2f7ca51b0929461ea49918f27c11b680f28995 •