Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: check for wq exit after adding new worker task_work<br /> <br /> We check IO_WQ_BIT_EXIT before attempting to create a new worker, and<br /> wq exit cancels pending work if we have any. But it&amp;#39;s possible to have<br /> a race between the two, where creation checks exit finding it not set,<br /> but we&amp;#39;re in the process of exiting. The exit side will cancel pending<br /> creation task_work, but there&amp;#39;s a gap where we add task_work after we&amp;#39;ve<br /> canceled existing creations at exit time.<br /> <br /> Fix this by checking the EXIT bit post adding the creation task_work.<br /> If it&amp;#39;s set, run the same cancelation that exit does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Don&amp;#39;t call kcalloc() if size arg is zero<br /> <br /> If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of<br /> that, for a following NULL pointer check to work on the returned pointer,<br /> kcalloc() must not be called with the size arg equal to zero. Return early<br /> without error before the kcalloc() call if size arg is zero.<br /> <br /> BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]<br /> BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> Write of size 4 at addr 0000000000000010 by task syz-executor.1/22789<br /> <br /> CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> __kasan_report mm/kasan/report.c:446 [inline]<br /> kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189<br /> memcpy+0x3b/0x60 mm/kasan/shadow.c:66<br /> memcpy include/linux/fortify-string.h:191 [inline]<br /> sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]<br /> resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276<br /> schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478<br /> scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533<br /> scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]<br /> scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62<br /> blk_execute_rq+0xdb/0x360 block/blk-exec.c:102<br /> sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]<br /> scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930<br /> sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix warning in ovl_create_real()<br /> <br /> Syzbot triggered the following warning in ovl_workdir_create() -&gt;<br /> ovl_create_real():<br /> <br /> if (!err &amp;&amp; WARN_ON(!newdentry-&gt;d_inode)) {<br /> <br /> The reason is that the cgroup2 filesystem returns from mkdir without<br /> instantiating the new dentry.<br /> <br /> Weird filesystems such as this will be rejected by overlayfs at a later<br /> stage during setup, but to prevent such a warning, call ovl_mkdir_real()<br /> directly from ovl_workdir_create() and reject this case early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix type in min_t to avoid stack OOB<br /> <br /> Change min_t() to use type "u32" instead of type "int" to avoid stack out<br /> of bounds. With min_t() type "int" the values get sign extended and the<br /> larger value gets used causing stack out of bounds.<br /> <br /> BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]<br /> BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976<br /> Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707<br /> <br /> CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189<br /> memcpy+0x23/0x60 mm/kasan/shadow.c:65<br /> memcpy include/linux/fortify-string.h:191 [inline]<br /> sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976<br /> sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000<br /> fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162<br /> fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]<br /> resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887<br /> schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478<br /> scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533<br /> scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]<br /> scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62<br /> sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836<br /> sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774<br /> sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Make do_proc_control() and do_proc_bulk() killable<br /> <br /> The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke<br /> usb_start_wait_urb(), which contains an uninterruptible wait with a<br /> user-specified timeout value. If timeout value is very large and the<br /> device being accessed does not respond in a reasonable amount of time,<br /> the kernel will complain about "Task X blocked for more than N<br /> seconds", as found in testing by syzbot:<br /> <br /> INFO: task syz-executor.0:8700 blocked for more than 143 seconds.<br /> Not tainted 5.14.0-rc7-syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004<br /> Call Trace:<br /> context_switch kernel/sched/core.c:4681 [inline]<br /> __schedule+0xc07/0x11f0 kernel/sched/core.c:5938<br /> schedule+0x14b/0x210 kernel/sched/core.c:6017<br /> schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857<br /> do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85<br /> __wait_for_common kernel/sched/completion.c:106 [inline]<br /> wait_for_common kernel/sched/completion.c:117 [inline]<br /> wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157<br /> usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63<br /> do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236<br /> proc_bulk drivers/usb/core/devio.c:1273 [inline]<br /> usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]<br /> usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713<br /> ...<br /> <br /> To fix this problem, this patch replaces usbfs&amp;#39;s calls to<br /> usb_control_msg() and usb_bulk_msg() with special-purpose code that<br /> does essentially the same thing (as recommended in the comment for<br /> usb_start_wait_urb()), except that it always uses a killable wait and<br /> it uses GFP_KERNEL rather than GFP_NOIO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mxl111sf: change mutex_init() location<br /> <br /> Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized<br /> mutex. The problem was in wrong mutex_init() location.<br /> <br /> Previous mutex_init(&amp;state-&gt;msg_lock) call was in -&gt;init() function, but<br /> dvb_usbv2_init() has this order of calls:<br /> <br /> dvb_usbv2_init()<br /> dvb_usbv2_adapter_init()<br /> dvb_usbv2_adapter_frontend_init()<br /> props-&gt;frontend_attach()<br /> <br /> props-&gt;init()<br /> <br /> Since mxl111sf_* devices call mxl111sf_ctrl_msg() in -&gt;frontend_attach()<br /> internally we need to initialize state-&gt;msg_lock before<br /> frontend_attach(). To achieve it, -&gt;probe() call added to all mxl111sf_*<br /> devices, which will simply initiaize mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iocost: Fix divide-by-zero on donation from low hweight cgroup<br /> <br /> The donation calculation logic assumes that the donor has non-zero<br /> after-donation hweight, so the lowest active hweight a donating cgroup can<br /> have is 2 so that it can donate 1 while keeping the other 1 for itself.<br /> Earlier, we only donated from cgroups with sizable surpluses so this<br /> condition was always true. However, with the precise donation algorithm<br /> implemented, f1de2439ec43 ("blk-iocost: revamp donation amount<br /> determination") made the donation amount calculation exact enabling even low<br /> hweight cgroups to donate.<br /> <br /> This means that in rare occasions, a cgroup with active hweight of 1 can<br /> enter donation calculation triggering the following warning and then a<br /> divide-by-zero oops.<br /> <br /> WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]<br /> ...<br /> RIP: 0010:transfer_surpluses.cold+0x0/0x53<br /> Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0<br /> 4<br /> ...<br /> Call Trace:<br /> <br /> ioc_timer_fn+0x1043/0x1390<br /> call_timer_fn+0xa1/0x2c0<br /> __run_timers.part.0+0x1ec/0x2e0<br /> run_timer_softirq+0x35/0x70<br /> ...<br /> iocg: invalid donation weights in /a/b: active=1 donating=1 after=0<br /> <br /> Fix it by excluding cgroups w/ active hweight

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Fix spinlock race in kernel thread creation<br /> <br /> Context switching does take care to retain the correct lock owner across<br /> the switch from &amp;#39;prev&amp;#39; to &amp;#39;next&amp;#39; tasks. This does rely on interrupts<br /> remaining disabled for the entire duration of the switch.<br /> <br /> This condition is guaranteed for normal process creation and context<br /> switching between already running processes, because both &amp;#39;prev&amp;#39; and<br /> &amp;#39;next&amp;#39; already have interrupts disabled in their saved copies of the<br /> status register.<br /> <br /> The situation is different for newly created kernel threads. The status<br /> register is set to PS_S in copy_thread(), which does leave the IPL at 0.<br /> Upon restoring the &amp;#39;next&amp;#39; thread&amp;#39;s status register in switch_to() aka<br /> resume(), interrupts then become enabled prematurely. resume() then<br /> returns via ret_from_kernel_thread() and schedule_tail() where run queue<br /> lock is released (see finish_task_switch() and finish_lock_switch()).<br /> <br /> A timer interrupt calling scheduler_tick() before the lock is released<br /> in finish_task_switch() will find the lock already taken, with the<br /> current task as lock owner. This causes a spinlock recursion warning as<br /> reported by Guenter Roeck.<br /> <br /> As far as I can ascertain, this race has been opened in commit<br /> 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")<br /> but I haven&amp;#39;t done a detailed study of kernel history so it may well<br /> predate that commit.<br /> <br /> Interrupts cannot be disabled in the saved status register copy for<br /> kernel threads (init will complain about interrupts disabled when<br /> finally starting user space). Disable interrupts temporarily when<br /> switching the tasks&amp;#39; register sets in resume().<br /> <br /> Note that a simple oriw 0x700,%sr after restoring sr is not enough here<br /> - this leaves enough of a race for the &amp;#39;spinlock recursion&amp;#39; warning to<br /> still be observed.<br /> <br /> Tested on ARAnyM and qemu (Quadra 800 emulation).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openrisc: traps: Don&amp;#39;t send signals to kernel mode threads<br /> <br /> OpenRISC exception handling sends signals to user processes on floating<br /> point exceptions and trap instructions (for debugging) among others.<br /> There is a bug where the trap handling logic may send signals to kernel<br /> threads, we should not send these signals to kernel threads, if that<br /> happens we treat it as an error.<br /> <br /> This patch adds conditions to die if the kernel receives these<br /> exceptions in kernel mode code.