CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47587 – net: systemport: Add global locking for descriptor lifecycle
https://notcve.org/view.php?id=CVE-2021-47587
In the Linux kernel, the following vulnerability has been resolved: net: systemport: Add global locking for descriptor lifecycle The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues. This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length. The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer. The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITE_PORT_{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: systemport: agregue bloqueo global para el ciclo de vida del descriptor. La lista de descriptores es un recurso compartido entre todas las colas de transmisión y el mecanismo de bloqueo que se usa hoy solo protege la concurrencia en una cola de transmisión determinada. entre la transmisión y la recuperación. • https://git.kernel.org/stable/c/80105befdb4b8cea924711b40b2462b87df65b62 https://git.kernel.org/stable/c/8ed2f5d08d6e59f8c78b2869bfb95d0be32c094c https://git.kernel.org/stable/c/de57f62f76450b934de8203711bdc4f7953c3421 https://git.kernel.org/stable/c/f3fde37d3f0d429f0fcce214cb52588a9e21260e https://git.kernel.org/stable/c/595a684fa6f23b21958379a18cfa83862c73c2e1 https://git.kernel.org/stable/c/c675256a7f131f5ba3f331efb715e8f31ea0e392 https://git.kernel.org/stable/c/6e1011cd183faae8daff275c72444edcdfe0d473 https://git.kernel.org/stable/c/eb4687c7442942e115420a30185f8d83f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47583 – media: mxl111sf: change mutex_init() location
https://notcve.org/view.php?id=CVE-2021-47583
In the Linux kernel, the following vulnerability has been resolved: media: mxl111sf: change mutex_init() location Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location. Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mxl111sf: cambiar la ubicación de mutex_init() Syzbot informó que mxl111sf_ctrl_msg() usa un mutex no inicializado. El problema estaba en la ubicación mutex_init() incorrecta. • https://git.kernel.org/stable/c/8572211842afc53c8450fb470f2b8d02ba7592e0 https://git.kernel.org/stable/c/4b2d9600b31f9ba7adbc9f3c54a068615d27b390 https://git.kernel.org/stable/c/96f182c9f48b984447741f054ec301fdc8517035 https://git.kernel.org/stable/c/b99bdf127af91d53919e96292c05f737c45ea59a https://git.kernel.org/stable/c/8c6fdf62bfe1bc72bfceeaf832ef7499c7ed09ba https://git.kernel.org/stable/c/44870a9e7a3c24acbb3f888b2a7cc22c9bdf7e7f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47582 – USB: core: Make do_proc_control() and do_proc_bulk() killable
https://notcve.org/view.php?id=CVE-2021-47582
In the Linux kernel, the following vulnerability has been resolved: USB: core: Make do_proc_control() and do_proc_bulk() killable The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot: INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713 ... To fix this problem, this patch replaces usbfs's calls to usb_control_msg() and usb_bulk_msg() with special-purpose code that does essentially the same thing (as recommended in the comment for usb_start_wait_urb()), except that it always uses a killable wait and it uses GFP_KERNEL rather than GFP_NOIO. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: Hacer que do_proc_control() y do_proc_bulk() se puedan eliminar. Los ioctls USBDEVFS_CONTROL y USBDEVFS_BULK invocan usb_start_wait_urb(), que contiene una espera ininterrumpida con un valor de tiempo de espera especificado por el usuario. Si el valor del tiempo de espera es muy grande y el dispositivo al que se accede no responde en un período de tiempo razonable, el kernel se quejará de "Tarea X bloqueada durante más de N segundos", como se encontró en las pruebas realizadas por syzbot: INFORMACIÓN: tarea syz-executor .0:8700 bloqueado durante más de 143 segundos. • https://git.kernel.org/stable/c/403716741c6c2c510dce44e88f085a740f535de6 https://git.kernel.org/stable/c/ae8709b296d80c7f45aa1f35c0e7659ad69edce1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47580 – scsi: scsi_debug: Fix type in min_t to avoid stack OOB
https://notcve.org/view.php?id=CVE-2021-47580
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix type in min_t to avoid stack OOB Change min_t() to use type "u32" instead of type "int" to avoid stack out of bounds. With min_t() type "int" the values get sign extended and the larger value gets used causing stack out of bounds. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline] resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: scsi_debug: corrige el tipo min_t para evitar la pila OOB. Cambie min_t() para usar el tipo "u32" en lugar de "int" para evitar la pila fuera de los límites. Con min_t() escriba "int", los valores se extienden y el valor mayor se usa provocando que la pila esté fuera de los límites. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: pila fuera de los límites en sg_copy_buffer+0x1de/0x240 lib/scatterlist.c: 976 Lectura del tamaño 127 en la dirección ffff888072607128 mediante la tarea syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0 -2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan /report.c:442 [en línea] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x1a3/0x210 mm/kasan/generic .c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [en línea] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 controladores/scsi/scsi_debug.c:1162 fill_from_dev_buffer controladores/scsi/scsi_debug.c:1888 [en línea] resp_readcap16+0x365/0x3b0 controladores/scsi/scsi_debug.c :1887 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi/scsi_lib.c:1520 [en línea] Controladores 0x16b0/0x2d40/ scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x10 5/0x190 cuadra/blk-mq-programado. c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 :1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570 /0x8c0 controladores/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 controladores/scsi/sg.c:939 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] llamada al sistema_64 +0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/bdb854f134b964528fa543e0351022eb45bd7346 https://git.kernel.org/stable/c/3085147645938eb41f0bc0e25ef9791e71f5ee4b https://git.kernel.org/stable/c/36e07d7ede88a1f1ef8f0f209af5b7612324ac2c •
CVSS: 4.1EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47579 – ovl: fix warning in ovl_create_real()
https://notcve.org/view.php?id=CVE-2021-47579
In the Linux kernel, the following vulnerability has been resolved: ovl: fix warning in ovl_create_real() Syzbot triggered the following warning in ovl_workdir_create() -> ovl_create_real(): if (!err && WARN_ON(!newdentry->d_inode)) { The reason is that the cgroup2 filesystem returns from mkdir without instantiating the new dentry. Weird filesystems such as this will be rejected by overlayfs at a later stage during setup, but to prevent such a warning, call ovl_mkdir_real() directly from ovl_workdir_create() and reject this case early. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corregir advertencia en ovl_create_real() Syzbot activó la siguiente advertencia en ovl_workdir_create() -> ovl_create_real(): if (!err && WARN_ON(! • https://git.kernel.org/stable/c/445d2dc63e5871d218f21b8f62ab29ac72f2e6b8 https://git.kernel.org/stable/c/f9f300a92297be8250547347fd52216ef0177ae0 https://git.kernel.org/stable/c/6859985a2fbda5d1586bf44538853e1be69e85f7 https://git.kernel.org/stable/c/d2ccdd4e4efab06178608a34d7bfb20a54104c02 https://git.kernel.org/stable/c/1f5573cfe7a7056e80a92c7a037a3e69f3a13d1c https://access.redhat.com/security/cve/CVE-2021-47579 https://bugzilla.redhat.com/show_bug.cgi?id=2293250 • CWE-457: Use of Uninitialized Variable •