Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert<br /> <br /> After commit 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked()<br /> annotations to find_vma*()"), the call to get_user_pages() will trigger<br /> the mmap assert.<br /> <br /> static inline void mmap_assert_locked(struct mm_struct *mm)<br /> {<br /> lockdep_assert_held(&amp;mm-&gt;mmap_lock);<br /> VM_BUG_ON_MM(!rwsem_is_locked(&amp;mm-&gt;mmap_lock), mm);<br /> }<br /> <br /> [ 62.521410] kernel BUG at include/linux/mmap_lock.h:156!<br /> ...........................................................<br /> [ 62.538938] RIP: 0010:find_vma+0x32/0x80<br /> ...........................................................<br /> [ 62.605889] Call Trace:<br /> [ 62.608502] <br /> [ 62.610956] ? lock_timer_base+0x61/0x80<br /> [ 62.614106] find_extend_vma+0x19/0x80<br /> [ 62.617195] __get_user_pages+0x9b/0x6a0<br /> [ 62.620356] __gup_longterm_locked+0x42d/0x450<br /> [ 62.623721] ? finish_wait+0x41/0x80<br /> [ 62.626748] ? __kmalloc+0x178/0x2f0<br /> [ 62.629768] ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves]<br /> [ 62.635776] ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves]<br /> [ 62.639541] __x64_sys_ioctl+0x82/0xb0<br /> [ 62.642620] do_syscall_64+0x3b/0x90<br /> [ 62.645642] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Use get_user_pages_unlocked() when setting the enclave memory regions.<br /> That&amp;#39;s a similar pattern as mmap_read_lock() used together with<br /> get_user_pages().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Clear stale IIR value on instruction access rights trap<br /> <br /> When a trap 7 (Instruction access rights) occurs, this means the CPU<br /> couldn&amp;#39;t execute an instruction due to missing execute permissions on<br /> the memory region. In this case it seems the CPU didn&amp;#39;t even fetched<br /> the instruction from memory and thus did not store it in the cr19 (IIR)<br /> register before calling the trap handler. So, the trap handler will find<br /> some random old stale value in cr19.<br /> <br /> This patch simply overwrites the stale IIR value with a constant magic<br /> "bad food" value (0xbaadf00d), in the hope people don&amp;#39;t start to try to<br /> understand the various random IIR values in trap 7 dumps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: use call_rcu to free endpoint<br /> <br /> This patch is to delay the endpoint free by calling call_rcu() to fix<br /> another use-after-free issue in sctp_sock_dump():<br /> <br /> BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20<br /> Call Trace:<br /> __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218<br /> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844<br /> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]<br /> _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168<br /> spin_lock_bh include/linux/spinlock.h:334 [inline]<br /> __lock_sock+0x203/0x350 net/core/sock.c:2253<br /> lock_sock_nested+0xfe/0x120 net/core/sock.c:2774<br /> lock_sock include/net/sock.h:1492 [inline]<br /> sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324<br /> sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091<br /> sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527<br /> __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049<br /> inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065<br /> netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244<br /> __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352<br /> netlink_dump_start include/linux/netlink.h:216 [inline]<br /> inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170<br /> __sock_diag_cmd net/core/sock_diag.c:232 [inline]<br /> sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263<br /> netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477<br /> sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274<br /> <br /> This issue occurs when asoc is peeled off and the old sk is freed after<br /> getting it by asoc-&gt;base.sk and before calling lock_sock(sk).<br /> <br /> To prevent the sk free, as a holder of the sk, ep should be alive when<br /> calling lock_sock(). This patch uses call_rcu() and moves sock_put and<br /> ep free into sctp_endpoint_destroy_rcu(), so that it&amp;#39;s safe to try to<br /> hold the ep under rcu_read_lock in sctp_transport_traverse_process().<br /> <br /> If sctp_endpoint_hold() returns true, it means this ep is still alive<br /> and we have held it and can continue to dump it; If it returns false,<br /> it means this ep is dead and can be freed after rcu_read_unlock, and<br /> we should skip it.<br /> <br /> In sctp_sock_dump(), after locking the sk, if this ep is different from<br /> tsp-&gt;asoc-&gt;ep, it means during this dumping, this asoc was peeled off<br /> before calling lock_sock(), and the sk should be skipped; If this ep is<br /> the same with tsp-&gt;asoc-&gt;ep, it means no peeloff happens on this asoc,<br /> and due to lock_sock, no peeloff will happen either until release_sock.<br /> <br /> Note that delaying endpoint free won&amp;#39;t delay the port release, as the<br /> port release happens in sctp_endpoint_destroy() before calling call_rcu().<br /> Also, freeing endpoint by call_rcu() makes it safe to access the sk by<br /> asoc-&gt;base.sk in sctp_assocs_seq_show() and sctp_rcv().<br /> <br /> Thanks Jones to bring this issue up.<br /> <br /> v1-&gt;v2:<br /> - improve the changelog.<br /> - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: mtu3: fix list_head check warning<br /> <br /> This is caused by uninitialization of list_head.<br /> <br /> BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4<br /> <br /> Call trace:<br /> dump_backtrace+0x0/0x298<br /> show_stack+0x24/0x34<br /> dump_stack+0x130/0x1a8<br /> print_address_description+0x88/0x56c<br /> __kasan_report+0x1b8/0x2a0<br /> kasan_report+0x14/0x20<br /> __asan_load8+0x9c/0xa0<br /> __list_del_entry_valid+0x34/0xe4<br /> mtu3_req_complete+0x4c/0x300 [mtu3]<br /> mtu3_gadget_stop+0x168/0x448 [mtu3]<br /> usb_gadget_unregister_driver+0x204/0x3a0<br /> unregister_gadget_item+0x44/0xa4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Wrap the tx reporter dump callback to extract the sq<br /> <br /> Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct<br /> mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually<br /> of type struct mlx5e_tx_timeout_ctx *.<br /> <br /> mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected<br /> mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000<br /> BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae)<br /> kernel stack overflow (page fault): 0000 [#1] SMP NOPTI<br /> CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #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: mlx5e mlx5e_tx_timeout_work [mlx5_core]<br /> RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180<br /> [mlx5_core]<br /> Call Trace:<br /> mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core]<br /> devlink_health_do_dump.part.91+0x71/0xd0<br /> devlink_health_report+0x157/0x1b0<br /> mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core]<br /> ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0<br /> [mlx5_core]<br /> ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]<br /> ? update_load_avg+0x19b/0x550<br /> ? set_next_entity+0x72/0x80<br /> ? pick_next_task_fair+0x227/0x340<br /> ? finish_task_switch+0xa2/0x280<br /> mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core]<br /> process_one_work+0x1de/0x3a0<br /> worker_thread+0x2d/0x3c0<br /> ? process_one_work+0x3a0/0x3a0<br /> kthread+0x115/0x130<br /> ? kthread_park+0x90/0x90<br /> ret_from_fork+0x1f/0x30<br /> --[ end trace 51ccabea504edaff ]---<br /> RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180<br /> PKRU: 55555554<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: disabled<br /> end Kernel panic - not syncing: Fatal exception<br /> <br /> To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which<br /> extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the<br /> TX-timeout-recovery flow dump callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: appletouch - initialize work before device registration<br /> <br /> Syzbot has reported warning in __flush_work(). This warning is caused by<br /> work-&gt;func == NULL, which means missing work initialization.<br /> <br /> This may happen, since input_dev-&gt;close() calls<br /> cancel_work_sync(&amp;dev-&gt;work), but dev-&gt;work initalization happens _after_<br /> input_register_device() call.<br /> <br /> So this patch moves dev-&gt;work initialization before registering input<br /> device

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: validate user data in compat ioctl<br /> <br /> Wrong user data may cause warning in i2c_transfer(), ex: zero msgs.<br /> Userspace should not be able to trigger warnings, so this patch adds<br /> validation checks for user data in compact ioctl to prevent reported<br /> warnings

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix async_free_space accounting for empty parcels<br /> <br /> In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")<br /> fixed a kernel structure visibility issue. As part of that patch,<br /> sizeof(void *) was used as the buffer size for 0-length data payloads so<br /> the driver could detect abusive clients sending 0-length asynchronous<br /> transactions to a server by enforcing limits on async_free_size.<br /> <br /> Unfortunately, on the "free" side, the accounting of async_free_space<br /> did not add the sizeof(void *) back. The result was that up to 8-bytes of<br /> async_free_space were leaked on every async transaction of 8-bytes or<br /> less. These small transactions are uncommon, so this accounting issue<br /> has gone undetected for several years.<br /> <br /> The fix is to use "buffer_size" (the allocated buffer size) instead of<br /> "size" (the logical buffer size) when updating the async_free_space<br /> during the free operation. These are the same except for this<br /> corner case of asynchronous transactions with payloads

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix kernel panic caused by race of smc_sock<br /> <br /> A crash occurs when smc_cdc_tx_handler() tries to access smc_sock<br /> but smc_release() has already freed it.<br /> <br /> [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88<br /> [ 4570.696048] #PF: supervisor write access in kernel mode<br /> [ 4570.696728] #PF: error_code(0x0002) - not-present page<br /> [ 4570.697401] PGD 0 P4D 0<br /> [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111<br /> [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0<br /> [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30<br /> <br /> [ 4570.711446] Call Trace:<br /> [ 4570.711746] <br /> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0<br /> [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560<br /> [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10<br /> [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140<br /> [ 4570.714083] __do_softirq+0x123/0x2f4<br /> [ 4570.714521] irq_exit_rcu+0xc4/0xf0<br /> [ 4570.714934] common_interrupt+0xba/0xe0<br /> <br /> Though smc_cdc_tx_handler() checked the existence of smc connection,<br /> smc_release() may have already dismissed and released the smc socket<br /> before smc_cdc_tx_handler() further visits it.<br /> <br /> smc_cdc_tx_handler() |smc_release()<br /> if (!conn) |<br /> |<br /> |smc_cdc_tx_dismiss_slots()<br /> | smc_cdc_tx_dismisser()<br /> |<br /> |sock_put(&amp;smc-&gt;sk) sk) (panic) |<br /> <br /> To make sure we won&amp;#39;t receive any CDC messages after we free the<br /> smc_sock, add a refcount on the smc_connection for inflight CDC<br /> message(posted to the QP but haven&amp;#39;t received related CQE), and<br /> don&amp;#39;t release the smc_connection until all the inflight CDC messages<br /> haven been done, for both success or failed ones.<br /> <br /> Using refcount on CDC messages brings another problem: when the link<br /> is going to be destroyed, smcr_link_clear() will reset the QP, which<br /> then remove all the pending CQEs related to the QP in the CQ. To make<br /> sure all the CQEs will always come back so the refcount on the<br /> smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced<br /> by smc_ib_modify_qp_error().<br /> And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we<br /> need to wait for all pending WQEs done, or we may encounter use-after-<br /> free when handling CQEs.<br /> <br /> For IB device removal routine, we need to wait for all the QPs on that<br /> device been destroyed before we can destroy CQs on the device, or<br /> the refcount on smc_connection won&amp;#39;t reach 0 and smc_sock cannot be<br /> released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.<br /> <br /> ffs_data_clear is indirectly called from both ffs_fs_kill_sb and<br /> ffs_ep0_release, so it ends up being called twice when userland closes ep0<br /> and then unmounts f_fs.<br /> If userland provided an eventfd along with function&amp;#39;s USB descriptors, it<br /> ends up calling eventfd_ctx_put as many times, causing a refcount<br /> underflow.<br /> NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.<br /> <br /> Also, set epfiles to NULL right after de-allocating it, for readability.<br /> <br /> For completeness, ffs_data_clear actually ends up being called thrice, the<br /> last call being before the whole ffs structure gets freed, so when this<br /> specific sequence happens there is a second underflow happening (but not<br /> being reported):<br /> <br /> /sys/kernel/debug/tracing# modprobe usb_f_fs<br /> /sys/kernel/debug/tracing# echo ffs_data_clear &gt; set_ftrace_filter<br /> /sys/kernel/debug/tracing# echo function &gt; current_tracer<br /> /sys/kernel/debug/tracing# echo 1 &gt; tracing_on<br /> (setup gadget, run and kill function userland process, teardown gadget)<br /> /sys/kernel/debug/tracing# echo 0 &gt; tracing_on<br /> /sys/kernel/debug/tracing# cat trace<br /> smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/qrwlock: Fix ordering in queued_write_lock_slowpath()<br /> <br /> While this code is executed with the wait_lock held, a reader can<br /> acquire the lock without holding wait_lock. The writer side loops<br /> checking the value with the atomic_cond_read_acquire(), but only truly<br /> acquires the lock when the compare-and-exchange is completed<br /> successfully which isn’t ordered. This exposes the window between the<br /> acquire and the cmpxchg to an A-B-A problem which allows reads<br /> following the lock acquisition to observe values speculatively before<br /> the write lock is truly acquired.<br /> <br /> We&amp;#39;ve seen a problem in epoll where the reader does a xchg while<br /> holding the read lock, but the writer can see a value change out from<br /> under it.<br /> <br /> Writer | Reader<br /> --------------------------------------------------------------------------------<br /> ep_scan_ready_list() |<br /> |- write_lock_irq() |<br /> |- queued_write_lock_slowpath() |<br /> |- atomic_cond_read_acquire() |<br /> | read_lock_irqsave(&amp;ep-&gt;lock, flags);<br /> --&gt; (observes value before unlock) | chain_epi_lockless()<br /> | | epi-&gt;next = xchg(&amp;ep-&gt;ovflist, epi);<br /> | | read_unlock_irqrestore(&amp;ep-&gt;lock, flags);<br /> | |<br /> | atomic_cmpxchg_relaxed() |<br /> |-- READ_ONCE(ep-&gt;ovflist); |<br /> <br /> A core can order the read of the ovflist ahead of the<br /> atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire<br /> semantics addresses this issue at which point the atomic_cond_read can<br /> be switched to use relaxed semantics.<br /> <br /> [peterz: use try_cmpxchg()]

The Page Builder: Pagelayer WordPress plugin before 1.8.1 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)