Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: Fix division by zero error on zero wsum<br /> <br /> When the weighted sum is zero the calculation of limit causes<br /> a division by zero error. Fix this by continuing to the next level.<br /> <br /> This was discovered by running as root:<br /> <br /> stress-ng --ioprio 0<br /> <br /> Fixes divison by error oops:<br /> <br /> [ 521.450556] divide error: 0000 [#1] SMP NOPTI<br /> [ 521.450766] CPU: 2 PID: 2684464 Comm: stress-ng-iopri Not tainted 6.2.1-1280.native #1<br /> [ 521.451117] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014<br /> [ 521.451627] RIP: 0010:bfqq_request_over_limit+0x207/0x400<br /> [ 521.451875] Code: 01 48 8d 0c c8 74 0b 48 8b 82 98 00 00 00 48 8d 0c c8 8b 85 34 ff ff ff 48 89 ca 41 0f af 41 50 48 d1 ea 48 98 48 01 d0 31 d2 f7 f1 41 39 41 48 89 85 34 ff ff ff 0f 8c 7b 01 00 00 49 8b 44<br /> [ 521.452699] RSP: 0018:ffffb1af84eb3948 EFLAGS: 00010046<br /> [ 521.452938] RAX: 000000000000003c RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 521.453262] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb1af84eb3978<br /> [ 521.453584] RBP: ffffb1af84eb3a30 R08: 0000000000000001 R09: ffff8f88ab8a4ba0<br /> [ 521.453905] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8f88ab8a4b18<br /> [ 521.454224] R13: ffff8f8699093000 R14: 0000000000000001 R15: ffffb1af84eb3970<br /> [ 521.454549] FS: 00005640b6b0b580(0000) GS:ffff8f88b3880000(0000) knlGS:0000000000000000<br /> [ 521.454912] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 521.455170] CR2: 00007ffcbcae4e38 CR3: 00000002e46de001 CR4: 0000000000770ee0<br /> [ 521.455491] PKRU: 55555554<br /> [ 521.455619] Call Trace:<br /> [ 521.455736] <br /> [ 521.455837] ? bfq_request_merge+0x3a/0xc0<br /> [ 521.456027] ? elv_merge+0x115/0x140<br /> [ 521.456191] bfq_limit_depth+0xc8/0x240<br /> [ 521.456366] __blk_mq_alloc_requests+0x21a/0x2c0<br /> [ 521.456577] blk_mq_submit_bio+0x23c/0x6c0<br /> [ 521.456766] __submit_bio+0xb8/0x140<br /> [ 521.457236] submit_bio_noacct_nocheck+0x212/0x300<br /> [ 521.457748] submit_bio_noacct+0x1a6/0x580<br /> [ 521.458220] submit_bio+0x43/0x80<br /> [ 521.458660] ext4_io_submit+0x23/0x80<br /> [ 521.459116] ext4_do_writepages+0x40a/0xd00<br /> [ 521.459596] ext4_writepages+0x65/0x100<br /> [ 521.460050] do_writepages+0xb7/0x1c0<br /> [ 521.460492] __filemap_fdatawrite_range+0xa6/0x100<br /> [ 521.460979] file_write_and_wait_range+0xbf/0x140<br /> [ 521.461452] ext4_sync_file+0x105/0x340<br /> [ 521.461882] __x64_sys_fsync+0x67/0x100<br /> [ 521.462305] ? syscall_exit_to_user_mode+0x2c/0x1c0<br /> [ 521.462768] do_syscall_64+0x3b/0xc0<br /> [ 521.463165] entry_SYSCALL_64_after_hwframe+0x5a/0xc4<br /> [ 521.463621] RIP: 0033:0x5640b6c56590<br /> [ 521.464006] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d 71 70 0e 00 00 74 17 b8 4a 00 00 00 0f 05 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: fix table blob use-after-free<br /> <br /> We are not allowed to return an error at this point.<br /> Looking at the code it looks like ret is always 0 at this<br /> point, but its not.<br /> <br /> t = find_table_lock(net, repl-&gt;name, &amp;ret, &amp;ebt_mutex);<br /> <br /> ... this can return a valid table, with ret != 0.<br /> <br /> This bug causes update of table-&gt;private with the new<br /> blob, but then frees the blob right away in the caller.<br /> <br /> Syzbot report:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168<br /> Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> kasan_report+0xbf/0x1f0 mm/kasan/report.c:517<br /> __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168<br /> ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372<br /> ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169<br /> cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613<br /> ...<br /> <br /> ip(6)tables appears to be ok (ret should be 0 at this point) but make<br /> this more obvious.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: EC: Fix oops when removing custom query handlers<br /> <br /> When removing custom query handlers, the handler might still<br /> be used inside the EC query workqueue, causing a kernel oops<br /> if the module holding the callback function was already unloaded.<br /> <br /> Fix this by flushing the EC query workqueue when removing<br /> custom query handlers.<br /> <br /> Tested on a Acer Travelmate 4002WLMi

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix tags leak when shrink nr_hw_queues<br /> <br /> Although we don&amp;#39;t need to realloc set-&gt;tags[] when shrink nr_hw_queues,<br /> we need to free them. Or these tags will be leaked.<br /> <br /> How to reproduce:<br /> 1. mount -t configfs configfs /mnt<br /> 2. modprobe null_blk nr_devices=0 submit_queues=8<br /> 3. mkdir /mnt/nullb/nullb0<br /> 4. echo 1 &gt; /mnt/nullb/nullb0/power<br /> 5. echo 4 &gt; /mnt/nullb/nullb0/submit_queues<br /> 6. rmdir /mnt/nullb/nullb0<br /> <br /> In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), then<br /> in step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).<br /> At last in step 6, only these 5 tags are freed, the other 4 tags leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: raa215300: Fix resource leak in case of error<br /> <br /> The clk_register_clkdev() allocates memory by calling vclkdev_alloc() and<br /> this memory is not freed in the error path. Similarly, resources allocated<br /> by clk_register_fixed_rate() are not freed in the error path.<br /> <br /> Fix these issues by using devm_clk_hw_register_fixed_rate() and<br /> devm_clk_hw_register_clkdev().<br /> <br /> After this, the static variable clk is not needed. Replace it with <br /> local variable hw in probe() and drop calling clk_unregister_fixed_rate()<br /> from raa215300_rtc_unregister_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix registration of 6Ghz-only phy without the full channel range<br /> <br /> Because of what seems to be a typo, a 6Ghz-only phy for which the BDF<br /> does not allow the 7115Mhz channel will fail to register:<br /> <br /> WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954<br /> Modules linked in: ath11k_pci sbsa_gwdt<br /> CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9<br /> Hardware name: Freebox V7R Board (DT)<br /> Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : wiphy_register+0x914/0x954<br /> lr : ieee80211_register_hw+0x67c/0xc10<br /> sp : ffffff800b123aa0<br /> x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418<br /> x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168<br /> x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014<br /> x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f<br /> x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd<br /> x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718<br /> x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006<br /> x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284<br /> x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> wiphy_register+0x914/0x954<br /> ieee80211_register_hw+0x67c/0xc10<br /> ath11k_mac_register+0x7c4/0xe10<br /> ath11k_core_qmi_firmware_ready+0x1f4/0x570<br /> ath11k_qmi_driver_event_work+0x198/0x590<br /> process_one_work+0x1b8/0x328<br /> worker_thread+0x6c/0x414<br /> kthread+0x100/0x104<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22<br /> ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22<br /> ath11k_pci 0002:01:00.0: failed to create pdev core: -22

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amba: bus: fix refcount leak<br /> <br /> commit 5de1540b7bc4 ("drivers/amba: create devices from device tree")<br /> increases the refcount of of_node, but not releases it in<br /> amba_device_release, so there is refcount leak. By using of_node_put<br /> to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: fix memory leak in wx_setup_rx_resources<br /> <br /> When wx_alloc_page_pool() failed in wx_setup_rx_resources(), it doesn&amp;#39;t<br /> release DMA buffer. Add dma_free_coherent() in the error path to release<br /> the DMA buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Only force 030 bus error if PC not in exception table<br /> <br /> __get_kernel_nofault() does copy data in supervisor mode when<br /> forcing a task backtrace log through /proc/sysrq_trigger.<br /> This is expected cause a bus error exception on e.g. NULL<br /> pointer dereferencing when logging a kernel task has no<br /> workqueue associated. This bus error ought to be ignored.<br /> <br /> Our 030 bus error handler is ill equipped to deal with this:<br /> <br /> Whenever ssw indicates a kernel mode access on a data fault,<br /> we don&amp;#39;t even attempt to handle the fault and instead always<br /> send a SEGV signal (or panic). As a result, the check<br /> for exception handling at the fault PC (buried in<br /> send_sig_fault() which gets called from do_page_fault()<br /> eventually) is never used.<br /> <br /> In contrast, both 040 and 060 access error handlers do not<br /> care whether a fault happened on supervisor mode access,<br /> and will call do_page_fault() on those, ultimately honoring<br /> the exception table.<br /> <br /> Add a check in bus_error030 to call do_page_fault() in case<br /> we do have an entry for the fault PC in our exception table.<br /> <br /> I had attempted a fix for this earlier in 2019 that did rely<br /> on testing pagefault_disabled() (see link below) to achieve<br /> the same thing, but this patch should be more generic.<br /> <br /> Tested on 030 Atari Falcon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: avoid a NULL dereference with unsupported widgets<br /> <br /> If an IPC4 topology contains an unsupported widget, its .module_info<br /> field won&amp;#39;t be set, then sof_ipc4_route_setup() will cause a kernel<br /> Oops trying to dereference it. Add a check for such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix missing mrioc-&gt;evtack_cmds initialization<br /> <br /> Commit c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")<br /> introduced an array mrioc-&gt;evtack_cmds but initialization of the array<br /> elements was missed. They are just zero cleared. The function<br /> mpi3mr_complete_evt_ack() refers host_tag field of the elements. Due to the<br /> zero value of the host_tag field, the function calls clear_bit() for<br /> mrico-&gt;evtack_cmds_bitmap with wrong bit index. This results in memory<br /> access to invalid address and "BUG: KASAN: use-after-free". This BUG was<br /> observed at eHBA-9600 firmware update to version 8.3.1.0. To fix it, add<br /> the missing initialization of mrioc-&gt;evtack_cmds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DOE: Fix destroy_work_on_stack() race<br /> <br /> The following debug object splat was observed in testing:<br /> <br /> ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510<br /> WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0<br /> ...<br /> Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work<br /> RIP: 0010:debug_print_object+0x7d/0xb0<br /> ...<br /> Call Trace:<br /> ? debug_print_object+0x7d/0xb0<br /> ? __pfx_doe_statemachine_work+0x10/0x10<br /> debug_object_free.part.0+0x11b/0x150<br /> doe_statemachine_work+0x45e/0x510<br /> process_one_work+0x1d4/0x3c0<br /> <br /> This occurs because destroy_work_on_stack() was called after signaling<br /> the completion in the calling thread. This creates a race between<br /> destroy_work_on_stack() and the task-&gt;work struct going out of scope in<br /> pci_doe().<br /> <br /> Signal the work complete after destroying the work struct. This is safe<br /> because signal_task_complete() is the final thing the work item does and<br /> the workqueue code is careful not to access the work struct after.