Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()<br /> <br /> In resp_mode_select() sanity check the block descriptor len to avoid UAF.<br /> <br /> BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> Read of size 1 at addr ffff888026670f50 by task scsicmd/15032<br /> <br /> CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257<br /> kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443<br /> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306<br /> resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483<br /> scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537<br /> scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640<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:1762<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839<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:63<br /> sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837<br /> sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775<br /> sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113

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: 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.

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 /> cpufreq: exit() callback is optional<br /> <br /> The exit() callback is optional and shouldn&amp;#39;t be called without checking<br /> a valid pointer first.<br /> <br /> Also, we must clear freq_table pointer even if the exit() callback isn&amp;#39;t<br /> present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: re-fix fortified-memset warning<br /> <br /> The carl9170_tx_release() function sometimes triggers a fortified-memset<br /> warning in my randconfig builds:<br /> <br /> In file included from include/linux/string.h:254,<br /> from drivers/net/wireless/ath/carl9170/tx.c:40:<br /> In function &amp;#39;fortify_memset_chk&amp;#39;,<br /> inlined from &amp;#39;carl9170_tx_release&amp;#39; at drivers/net/wireless/ath/carl9170/tx.c:283:2,<br /> inlined from &amp;#39;kref_put&amp;#39; at include/linux/kref.h:65:3,<br /> inlined from &amp;#39;carl9170_tx_put_skb&amp;#39; at drivers/net/wireless/ath/carl9170/tx.c:342:9:<br /> include/linux/fortify-string.h:493:25: error: call to &amp;#39;__write_overflow_field&amp;#39; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]<br /> 493 | __write_overflow_field(p_size_field, size);<br /> <br /> Kees previously tried to avoid this by using memset_after(), but it seems<br /> this does not fully address the problem. I noticed that the memset_after()<br /> here is done on a different part of the union (status) than the original<br /> cast was from (rate_driver_data), which may confuse the compiler.<br /> <br /> Unfortunately, the memset_after() trick does not work on driver_rates[]<br /> because that is part of an anonymous struct, and I could not get<br /> struct_group() to do this either. Using two separate memset() calls<br /> on the two members does address the warning though.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kunit/fortify: Fix mismatched kvalloc()/vfree() usage<br /> <br /> The kv*() family of tests were accidentally freeing with vfree() instead<br /> of kvfree(). Use kvfree() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Set lower bound of start tick time<br /> <br /> Currently ALSA timer doesn&amp;#39;t have the lower limit of the start tick<br /> time, and it allows a very small size, e.g. 1 tick with 1ns resolution<br /> for hrtimer. Such a situation may lead to an unexpected RCU stall,<br /> where the callback repeatedly queuing the expire update, as reported<br /> by fuzzer.<br /> <br /> This patch introduces a sanity check of the timer start tick time, so<br /> that the system returns an error when a too small start size is set.<br /> As of this patch, the lower limit is hard-coded to 100us, which is<br /> small enough but can still work somehow.