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: 3.3EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52703 – net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
https://notcve.org/view.php?id=CVE-2023-52703
In the Linux kernel, the following vulnerability has been resolved: net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/usb: kalmia: No pasar act_len en la ruta de error usb_bulk_msg syzbot informó que act_len en kalmia_send_init_packet() no está inicializado al pasarlo a la primera ruta de error usb_bulk_msg. Jiri Pirko señaló que no tiene sentido pasarlo en la ruta de error y que el valor que se imprimiría en la segunda ruta de error sería el valor de act_len de la primera llamada a usb_bulk_msg.[1] Con esto en mente, simplemente no pasemos act_len a las rutas de error usb_bulk_msg. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ • https://git.kernel.org/stable/c/d40261236e8e278cb1936cb5e934262971692b10 https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5 https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081 https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042 https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030 https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a • CWE-15: External Control of System or Configuration Setting •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52700 – tipc: fix kernel warning when sending SYN message
https://notcve.org/view.php?id=CVE-2023-52700
In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel warning when sending SYN message When sending a SYN message, this kernel stack trace is observed: ... [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550 ... [ 13.398494] Call Trace: [ 13.398630] <TASK> [ 13.398630] ? __alloc_skb+0xed/0x1a0 [ 13.398630] tipc_msg_build+0x12c/0x670 [tipc] [ 13.398630] ? shmem_add_to_page_cache.isra.71+0x151/0x290 [ 13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc] [ 13.398630] ? tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? __local_bh_enable_ip+0x37/0x80 [ 13.398630] tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? • https://git.kernel.org/stable/c/f25dcc7687d42a72de18aa41b04990a24c9e77c7 https://git.kernel.org/stable/c/54b6082aec178f16ad6d193b4ecdc9c4823d9a32 https://git.kernel.org/stable/c/11a4d6f67cf55883dc78e31c247d1903ed7feccc https://access.redhat.com/security/cve/CVE-2023-52700 https://bugzilla.redhat.com/show_bug.cgi?id=2282609 • CWE-20: Improper Input Validation •
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 •