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 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46944 – media: staging/intel-ipu3: Fix memory leak in imu_fmt
https://notcve.org/view.php?id=CVE-2021-46944
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Reparar pérdida de memoria en imu_fmt Estamos perdiendo la referencia a una memoria asignada si lo intentamos. Cambie el orden del cheque para evitarlo. • https://git.kernel.org/stable/c/6d5f26f2e045f2377b524516194657c00efbbce8 https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9 https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3 https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46943 – media: staging/intel-ipu3: Fix set_fmt error handling
https://notcve.org/view.php?id=CVE-2021-46943
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Corrija el manejo de errores set_fmt Si ocurre un error durante un set_fmt, no sobrescriba los tamaños anteriores con la configuración no válida. Sin este parche, el cumplimiento de v4l2 termina asignando 4 GiB de RAM y provocando los siguientes OOP [38.662975] ipu3-imgu 0000:00:05.0: el búfer swiotlb está lleno (sz: 4096 bytes) [38.662980] DMA: Fuera de SW-IOMMU espacio para 4096 bytes en el dispositivo 0000:00:05.0 [38.663010] falla de protección general: 0000 [#1] PREEMPT SMP • https://git.kernel.org/stable/c/6d5f26f2e045f2377b524516194657c00efbbce8 https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6 https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137 https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916 https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356 • CWE-131: Incorrect Calculation of Buffer Size •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46942 – io_uring: fix shared sqpoll cancellation hangs
https://notcve.org/view.php?id=CVE-2021-46942
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix shared sqpoll cancellation hangs [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it's intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don't forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige bloqueos de cancelación de sqpoll compartido [736.982891] INFORMACIÓN: tarea iou-sqp-4294:4295 bloqueada durante más de 122 segundos. [ 736.982897] Seguimiento de llamadas: [ 736.982901] agenda+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 Llamamos a io_uring_cancel_sqpoll( ) uno por uno para cada ctx, ya sea en sq_thread() o mediante tareas, y está destinado a cancelar todas las solicitudes de un contexto específico. Sin embargo, la función utiliza contadores por tarea para rastrear la cantidad de solicitudes en curso, por lo que cuenta más solicitudes de las disponibles a través de currect io_uring ctx y se pone en suspensión para que aparezcan (por ejemplo, desde IRQ), eso nunca sucederá. • https://git.kernel.org/stable/c/37d1e2e3642e2380750d7f35279180826f29660e https://git.kernel.org/stable/c/cb5e0b3d0f993a6268c1a2c7ede2f9aa0c17ef68 https://git.kernel.org/stable/c/734551df6f9bedfbefcd113ede665945e9de0b99 •