CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52732 – ceph: blocklist the kclient when receiving corrupted snap trace
https://notcve.org/view.php?id=CVE-2023-52732
In the Linux kernel, the following vulnerability has been resolved: ceph: blocklist the kclient when receiving corrupted snap trace When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents. This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself. The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: lista de bloqueo del kclient cuando se recibe un seguimiento instantáneo corrupto. Cuando recibimos un seguimiento instantáneo corrupto, no sabemos qué ha sucedido exactamente en el lado MDS. Y no debemos continuar con el acceso de IO y metadatos a MDS, lo que puede dañar u obtener contenidos incorrectos. • https://git.kernel.org/stable/c/66ec619e4591f8350f99c5269a7ce160cccc7a7c https://git.kernel.org/stable/c/a68e564adcaa69b0930809fb64d9d5f7d9c32ba9 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52705 – nilfs2: fix underflow in second superblock position calculations
https://notcve.org/view.php?id=CVE-2023-52705
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix underflow in second superblock position calculations Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur. The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024) In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ... This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el desbordamiento en los cálculos de la posición del segundo superbloque. La macro NILFS_SB2_OFFSET_BYTES, que calcula la posición del segundo superbloque, sufre un desbordamiento cuando el tamaño del dispositivo del argumento es inferior a 4096 bytes. • https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5 https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205 https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4 https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48706 – vdpa: ifcvf: Do proper cleanup if IFCVF init fails
https://notcve.org/view.php?id=CVE-2022-48706
In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vdpa: ifcvf: realice una limpieza adecuada si falla el inicio de IFCVF. ifcvf_mgmt_dev pierde memoria si no se libera antes de regresar. Se realiza una llamada para corregir la declaración de devolución para que no se pierda memoria. ifcvf_init_hw no se encarga de esto, por lo que es necesario hacerlo aquí. • https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47431 – drm/amdgpu: fix gart.bo pin_count leak
https://notcve.org/view.php?id=CVE-2021-47431
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gart.bo pin_count leak gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador. • https://git.kernel.org/stable/c/83d857d6b0967b6709cd38750c3ce2ed8ced1a95 https://git.kernel.org/stable/c/621ddffb70db824eabd63d18ac635180fe9500f9 https://git.kernel.org/stable/c/18d1c5ea3798ba42cfa0f8b2264d873463facb03 https://git.kernel.org/stable/c/66805763a97f8f7bdf742fc0851d85c02ed9411f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47412 – block: don't call rq_qos_ops->done_bio if the bio isn't tracked
https://notcve.org/view.php?id=CVE-2021-47412
In the Linux kernel, the following vulnerability has been resolved: block: don't call rq_qos_ops->done_bio if the bio isn't tracked rq_qos framework is only applied on request based driver, so: 1) rq_qos_done_bio() needn't to be called for bio based driver 2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code. Especially in bio_endio(): 1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases 2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio() Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. • https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3 •