Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"<br /> <br /> The via-macii ADB driver calls request_irq() after disabling hard<br /> interrupts. But disabling interrupts isn&amp;#39;t necessary here because the<br /> VIA shift register interrupt was masked during VIA1 initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix netif state handling<br /> <br /> mlx5e_suspend cleans resources only if netif_device_present() returns<br /> true. However, mlx5e_resume changes the state of netif, via<br /> mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.<br /> In the below case, the above leads to NULL-ptr Oops[1] and memory<br /> leaks:<br /> <br /> mlx5e_probe<br /> _mlx5e_resume<br /> mlx5e_attach_netdev<br /> mlx5e_nic_enable

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: connac: check for null before dereferencing<br /> <br /> The wcid can be NULL. It should be checked for validity before<br /> dereferencing it to avoid crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()<br /> <br /> Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".<br /> <br /> Patch #1 fixes a bunch of issues I spotted in the acrn driver. It<br /> compiles, that&amp;#39;s all I know. I&amp;#39;ll appreciate some review and testing from<br /> acrn folks.<br /> <br /> Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding<br /> more sanity checks, and improving the documentation. Gave it a quick test<br /> on x86-64 using VM_PAT that ends up using follow_pte().<br /> <br /> <br /> This patch (of 3):<br /> <br /> We currently miss handling various cases, resulting in a dangerous<br /> follow_pte() (previously follow_pfn()) usage.<br /> <br /> (1) We&amp;#39;re not checking PTE write permissions.<br /> <br /> Maybe we should simply always require pte_write() like we do for<br /> pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let&amp;#39;s check for<br /> ACRN_MEM_ACCESS_WRITE for now.<br /> <br /> (2) We&amp;#39;re not rejecting refcounted pages.<br /> <br /> As we are not using MMU notifiers, messing with refcounted pages is<br /> dangerous and can result in use-after-free. Let&amp;#39;s make sure to reject them.<br /> <br /> (3) We are only looking at the first PTE of a bigger range.<br /> <br /> We only lookup a single PTE, but memmap-&gt;len may span a larger area.<br /> Let&amp;#39;s loop over all involved PTEs and make sure the PFN range is<br /> actually contiguous. Reject everything else: it couldn&amp;#39;t have worked<br /> either way, and rather made use access PFNs we shouldn&amp;#39;t be accessing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: et8ek8: Don&amp;#39;t strip remove function when driver is builtin<br /> <br /> Using __exit for the remove function results in the remove callback<br /> being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets<br /> unbound (e.g. using sysfs or hotplug), the driver is just removed<br /> without the cleanup being performed. This results in resource leaks. Fix<br /> it by compiling in the remove callback unconditionally.<br /> <br /> This also fixes a W=1 modpost warning:<br /> <br /> WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -&gt; et8ek8_remove (section: .exit.text)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix a race between readers and resize checks<br /> <br /> The reader code in rb_get_reader_page() swaps a new reader page into the<br /> ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the<br /> new page. Following that, if the operation is successful,<br /> old-&gt;list.next-&gt;prev gets updated too. This means the underlying<br /> doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or<br /> page-&gt;next-&gt;prev might not be equal back to page for some page in the<br /> ring buffer.<br /> <br /> The resize operation in ring_buffer_resize() can be invoked in parallel.<br /> It calls rb_check_pages() which can detect the described inconsistency<br /> and stop further tracing:<br /> <br /> [ 190.271762] ------------[ cut here ]------------<br /> [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0<br /> [ 190.271789] Modules linked in: [...]<br /> [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1<br /> [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f<br /> [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014<br /> [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0<br /> [ 190.272023] Code: [...]<br /> [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206<br /> [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80<br /> [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700<br /> [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000<br /> [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720<br /> [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000<br /> [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000<br /> [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0<br /> [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 190.272077] Call Trace:<br /> [ 190.272098] <br /> [ 190.272189] ring_buffer_resize+0x2ab/0x460<br /> [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0<br /> [ 190.272206] tracing_resize_ring_buffer+0x65/0x90<br /> [ 190.272216] tracing_entries_write+0x74/0xc0<br /> [ 190.272225] vfs_write+0xf5/0x420<br /> [ 190.272248] ksys_write+0x67/0xe0<br /> [ 190.272256] do_syscall_64+0x82/0x170<br /> [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 190.272373] RIP: 0033:0x7f1bd657d263<br /> [ 190.272381] Code: [...]<br /> [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263<br /> [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001<br /> [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000<br /> [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500<br /> [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002<br /> [ 190.272412] <br /> [ 190.272414] ---[ end trace 0000000000000000 ]---<br /> <br /> Note that ring_buffer_resize() calls rb_check_pages() only if the parent<br /> trace_buffer has recording disabled. Recent commit d78ab792705c<br /> ("tracing: Stop current tracer when resizing buffer") causes that it is<br /> now always the case which makes it more likely to experience this issue.<br /> <br /> The window to hit this race is nonetheless very small. To help<br /> reproducing it, one can add a delay loop in rb_get_reader_page():<br /> <br /> ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);<br /> if (!ret)<br /> goto spin;<br /> for (unsigned i = 0; i reader_page-&gt;list;<br /> <br /> .. <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: move the EST lock to struct stmmac_priv<br /> <br /> Reinitialize the whole EST structure would also reset the mutex<br /> lock which is embedded in the EST structure, and then trigger<br /> the following warning. To address this, move the lock to struct<br /> stmmac_priv. We also need to reacquire the mutex lock when doing<br /> this initialization.<br /> <br /> DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068<br /> Modules linked in:<br /> CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29<br /> Hardware name: NXP i.MX8MPlus EVK board (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __mutex_lock+0xd84/0x1068<br /> lr : __mutex_lock+0xd84/0x1068<br /> sp : ffffffc0864e3570<br /> x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003<br /> x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac<br /> x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff<br /> x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000<br /> x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8<br /> x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698<br /> x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001<br /> x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027<br /> x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> __mutex_lock+0xd84/0x1068<br /> mutex_lock_nested+0x28/0x34<br /> tc_setup_taprio+0x118/0x68c<br /> stmmac_setup_tc+0x50/0xf0<br /> taprio_change+0x868/0xc9c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix peer devlink set for SF representor devlink port<br /> <br /> The cited patch change register devlink flow, and neglect to reflect<br /> the changes for peer devlink set logic. Peer devlink set is<br /> triggering a call trace if done after devl_register.[1]<br /> <br /> Hence, align peer devlink set logic with register devlink flow.<br /> <br /> [1]<br /> WARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180<br /> CPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core]<br /> RIP: 0010:devlink_rel_nested_in_add+0x177/0x180<br /> Call Trace:<br /> <br /> ? __warn+0x78/0x120<br /> ? devlink_rel_nested_in_add+0x177/0x180<br /> ? report_bug+0x16d/0x180<br /> ? handle_bug+0x3c/0x60<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? devlink_port_init+0x30/0x30<br /> ? devlink_port_type_clear+0x50/0x50<br /> ? devlink_rel_nested_in_add+0x177/0x180<br /> ? devlink_rel_nested_in_add+0xdd/0x180<br /> mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core]<br /> notifier_call_chain+0x35/0xb0<br /> blocking_notifier_call_chain+0x3d/0x60<br /> mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]<br /> mlx5_sf_dev_probe+0x185/0x3e0 [mlx5_core]<br /> auxiliary_bus_probe+0x38/0x80<br /> ? driver_sysfs_add+0x51/0x80<br /> really_probe+0xc5/0x3a0<br /> ? driver_probe_device+0x90/0x90<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> bus_for_each_drv+0x80/0xd0<br /> __device_attach+0xbc/0x1f0<br /> bus_probe_device+0x86/0xa0<br /> device_add+0x64f/0x860<br /> __auxiliary_device_add+0x3b/0xa0<br /> mlx5_sf_dev_add+0x139/0x330 [mlx5_core]<br /> mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core]<br /> notifier_call_chain+0x35/0xb0<br /> blocking_notifier_call_chain+0x3d/0x60<br /> mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core]<br /> process_one_work+0x13f/0x2e0<br /> worker_thread+0x2bd/0x3c0<br /> ? rescuer_thread+0x410/0x410<br /> kthread+0xc4/0xf0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x2d/0x50<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork_asm+0x11/0x20<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Modify the print level of CQE error<br /> <br /> Too much print may lead to a panic in kernel. Change ibdev_err() to<br /> ibdev_err_ratelimited(), and change the printing level of cqe dump<br /> to debug level.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Init `ddp_comp` with devm_kcalloc()<br /> <br /> In the case where `conn_routes` is true we allocate an extra slot in<br /> the `ddp_comp` array but mtk_drm_crtc_create() never seemed to<br /> initialize it in the test case I ran. For me, this caused a later<br /> crash when we looped through the array in mtk_drm_crtc_mode_valid().<br /> This showed up for me when I booted with `slub_debug=FZPUA` which<br /> poisons the memory initially. Without `slub_debug` I couldn&amp;#39;t<br /> reproduce, presumably because the later code handles the value being<br /> NULL and in most cases (not guaranteed in all cases) the memory the<br /> allocator returned started out as 0.<br /> <br /> It really doesn&amp;#39;t hurt to initialize the array with devm_kcalloc()<br /> since the array is small and the overhead of initting a handful of<br /> elements to 0 is small. In general initting memory to zero is a safer<br /> practice and usually it&amp;#39;s suggested to only use the non-initting alloc<br /> functions if you really need to.<br /> <br /> Let&amp;#39;s switch the function to use an allocation function that zeros the<br /> memory. For me, this avoids the crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: micrel: Fix receiving the timestamp in the frame for lan8841<br /> <br /> The blamed commit started to use the ptp workqueue to get the second<br /> part of the timestamp. And when the port was set down, then this<br /> workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING<br /> is not enabled, then the ptp_clock is not initialized so then it would<br /> crash when it would try to access the delayed work.<br /> So then basically by setting up and then down the port, it would crash.<br /> The fix consists in checking if the ptp_clock is initialized and only<br /> then cancel the delayed work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: sungem: remove .ndo_poll_controller to avoid deadlocks<br /> <br /> Erhard reports netpoll warnings from sungem:<br /> <br /> netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)<br /> WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c<br /> <br /> gem_poll_controller() disables interrupts, which may sleep.<br /> We can&amp;#39;t sleep in netpoll, it has interrupts disabled completely.<br /> Strangely, gem_poll_controller() doesn&amp;#39;t even poll the completions,<br /> and instead acts as if an interrupt has fired so it just schedules<br /> NAPI and exits. None of this has been necessary for years, since<br /> netpoll invokes NAPI directly.