Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix pte update for kernel memory on radix<br /> <br /> When adding a PTE a ptesync is needed to order the update of the PTE<br /> with subsequent accesses otherwise a spurious fault may be raised.<br /> <br /> radix__set_pte_at() does not do this for performance gains. For<br /> non-kernel memory this is not an issue as any faults of this kind are<br /> corrected by the page fault handler. For kernel memory these faults<br /> are not handled. The current solution is that there is a ptesync in<br /> flush_cache_vmap() which should be called when mapping from the<br /> vmalloc region.<br /> <br /> However, map_kernel_page() does not call flush_cache_vmap(). This is<br /> troublesome in particular for code patching with Strict RWX on radix.<br /> In do_patch_instruction() the page frame that contains the instruction<br /> to be patched is mapped and then immediately patched. With no ordering<br /> or synchronization between setting up the PTE and writing to the page<br /> it is possible for faults.<br /> <br /> As the code patching is done using __put_user_asm_goto() the resulting<br /> fault is obscured - but using a normal store instead it can be seen:<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c<br /> Faulting instruction address: 0xc00000000008bd74<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in: nop_module(PO+) [last unloaded: nop_module]<br /> CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43<br /> NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810<br /> REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty)<br /> MSR: 9000000000009033 CR: 44002884 XER: 00000000<br /> CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1<br /> <br /> This results in the kind of issue reported here:<br /> https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/<br /> <br /> Chris Riedl suggested a reliable way to reproduce the issue:<br /> $ mount -t debugfs none /sys/kernel/debug<br /> $ (while true; do echo function &gt; /sys/kernel/debug/tracing/current_tracer ; echo nop &gt; /sys/kernel/debug/tracing/current_tracer ; done) &amp;<br /> <br /> Turning ftrace on and off does a large amount of code patching which<br /> in usually less then 5min will crash giving a trace like:<br /> <br /> ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000)<br /> ------------[ ftrace bug ]------------<br /> ftrace failed to modify<br /> [] napi_busy_loop+0xc/0x390<br /> actual: 11:3b:47:4b<br /> Setting ftrace call site to call ftrace function<br /> ftrace record flags: 80000001<br /> (1)<br /> expected tramp: c00000000006c96c<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8<br /> Modules linked in: nop_module(PO-) [last unloaded: nop_module]<br /> CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1<br /> NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0<br /> REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a)<br /> MSR: 900000000282b033 CR: 28008848 XER: 20040000<br /> CFAR: c0000000001a9c98 IRQMASK: 0<br /> GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022<br /> GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8<br /> GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118<br /> GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000<br /> GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008<br /> GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8<br /> GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020<br /> GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0<br /> NIP ftrace_bug+0x28c/0x2e8<br /> LR ftrace_bug+0x288/0x2e8<br /> Call T<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Remove WO permissions on second-level paging entries<br /> <br /> When the first level page table is used for IOVA translation, it only<br /> supports Read-Only and Read-Write permissions. The Write-Only permission<br /> is not supported as the PRESENT bit (implying Read permission) should<br /> always set. When using second level, we still give separate permissions<br /> that allows WriteOnly which seems inconsistent and awkward. We want to<br /> have consistent behavior. After moving to 1st level, we don&amp;#39;t want things<br /> to work sometimes, and break if we use 2nd level for the same mappings.<br /> Hence remove this configuration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: skip L4 aggregation for UDP tunnel packets<br /> <br /> If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there<br /> are UDP tunnels available in the system, udp_gro_receive() could end-up<br /> doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at<br /> the outer UDP tunnel level for packets effectively carrying and UDP<br /> tunnel header.<br /> <br /> That could cause inner protocol corruption. If e.g. the relevant<br /> packets carry a vxlan header, different vxlan ids will be ignored/<br /> aggregated to the same GSO packet. Inner headers will be ignored, too,<br /> so that e.g. TCP over vxlan push packets will be held in the GRO<br /> engine till the next flush, etc.<br /> <br /> Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the<br /> current packet could land in a UDP tunnel, and let udp_gro_receive()<br /> do GRO via udp_sk(sk)-&gt;gro_receive.<br /> <br /> The check implemented in this patch is broader than what is strictly<br /> needed, as the existing UDP tunnel could be e.g. configured on top of<br /> a different device: we could end-up skipping GRO at-all for some packets.<br /> <br /> Anyhow, that is a very thin corner case and covering it will add quite<br /> a bit of complexity.<br /> <br /> v1 -&gt; v2:<br /> - hopefully clarify the commit message

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: avoid deadlock between hci_dev-&gt;lock and socket lock<br /> <br /> Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a<br /> dependency between socket lock and hci_dev-&gt;lock that could lead to<br /> deadlock.<br /> <br /> It turns out that hci_conn_get_phy() is not in any way relying on hdev<br /> being immutable during the runtime of this function, neither does it even<br /> look at any of the members of hdev, and as such there is no need to hold<br /> that lock.<br /> <br /> This fixes the lockdep splat below:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 5.12.0-rc1-00026-g73d464503354 #10 Not tainted<br /> ------------------------------------------------------<br /> bluetoothd/1118 is trying to acquire lock:<br /> ffff8f078383c078 (&amp;hdev-&gt;lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> <br /> but task is already holding lock:<br /> ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}:<br /> lock_sock_nested+0x72/0xa0<br /> l2cap_sock_ready_cb+0x18/0x70 [bluetooth]<br /> l2cap_config_rsp+0x27a/0x520 [bluetooth]<br /> l2cap_sig_channel+0x658/0x1330 [bluetooth]<br /> l2cap_recv_frame+0x1ba/0x310 [bluetooth]<br /> hci_rx_work+0x1cc/0x640 [bluetooth]<br /> process_one_work+0x244/0x5f0<br /> worker_thread+0x3c/0x380<br /> kthread+0x13e/0x160<br /> ret_from_fork+0x22/0x30<br /> <br /> -&gt; #2 (&amp;chan-&gt;lock#2/1){+.+.}-{3:3}:<br /> __mutex_lock+0xa3/0xa10<br /> l2cap_chan_connect+0x33a/0x940 [bluetooth]<br /> l2cap_sock_connect+0x141/0x2a0 [bluetooth]<br /> __sys_connect+0x9b/0xc0<br /> __x64_sys_connect+0x16/0x20<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> -&gt; #1 (&amp;conn-&gt;chan_lock){+.+.}-{3:3}:<br /> __mutex_lock+0xa3/0xa10<br /> l2cap_chan_connect+0x322/0x940 [bluetooth]<br /> l2cap_sock_connect+0x141/0x2a0 [bluetooth]<br /> __sys_connect+0x9b/0xc0<br /> __x64_sys_connect+0x16/0x20<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> -&gt; #0 (&amp;hdev-&gt;lock){+.+.}-{3:3}:<br /> __lock_acquire+0x147a/0x1a50<br /> lock_acquire+0x277/0x3d0<br /> __mutex_lock+0xa3/0xa10<br /> hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth]<br /> __sys_getsockopt+0xcc/0x200<br /> __x64_sys_getsockopt+0x20/0x30<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> other info that might help us debug this:<br /> <br /> Chain exists of:<br /> &amp;hdev-&gt;lock --&gt; &amp;chan-&gt;lock#2/1 --&gt; sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);<br /> lock(&amp;chan-&gt;lock#2/1);<br /> lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);<br /> lock(&amp;hdev-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 1 lock held by bluetoothd/1118:<br /> #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth]<br /> <br /> stack backtrace:<br /> CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10<br /> Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017<br /> Call Trace:<br /> dump_stack+0x7f/0xa1<br /> check_noncircular+0x105/0x120<br /> ? __lock_acquire+0x147a/0x1a50<br /> __lock_acquire+0x147a/0x1a50<br /> lock_acquire+0x277/0x3d0<br /> ? hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> ? __lock_acquire+0x2e1/0x1a50<br /> ? lock_is_held_type+0xb4/0x120<br /> ? hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> __mutex_lock+0xa3/0xa10<br /> ? hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> ? lock_acquire+0x277/0x3d0<br /> ? mark_held_locks+0x49/0x70<br /> ? mark_held_locks+0x49/0x70<br /> ? hci_conn_get_phy+0x1c/0x150 [bluetooth]<br /> hci_conn_get_phy+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ataflop: potential out of bounds in do_format()<br /> <br /> The function uses "type" as an array index:<br /> <br /> q = unit[drive].disk[type]-&gt;queue;<br /> <br /> Unfortunately the bounds check on "type" isn&amp;#39;t done until later in the<br /> function. Fix this by moving the bounds check to the start.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix overflows checks in provide buffers<br /> <br /> Colin reported before possible overflow and sign extension problems in<br /> io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing<br /> useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension").<br /> <br /> Do that with help of check__overflow helpers. And fix struct<br /> io_provide_buf::len type, as it doesn&amp;#39;t make much sense to keep it<br /> signed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: q6afe-clocks: fix reprobing of the driver<br /> <br /> Q6afe-clocks driver can get reprobed. For example if the APR services<br /> are restarted after the firmware crash. However currently Q6afe-clocks<br /> driver will oops because hw.init will get cleared during first _probe<br /> call. Rewrite the driver to fill the clock data at runtime rather than<br /> using big static array of clocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: do asoc update earlier in sctp_sf_do_dupcook_a<br /> <br /> There&amp;#39;s a panic that occurs in a few of envs, the call trace is as below:<br /> <br /> [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI<br /> [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]<br /> [] sctp_assoc_control_transport+0x1b9/0x210 [sctp]<br /> [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]<br /> [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]<br /> [] sctp_do_sm+0xc3/0x2a0 [sctp]<br /> [] sctp_generate_timeout_event+0x81/0xf0 [sctp]<br /> <br /> This is caused by a transport use-after-free issue. When processing a<br /> duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK<br /> and SHUTDOWN chunks are allocated with the transort from the new asoc.<br /> However, later in the sideeffect machine, the old asoc is used to send<br /> them out and old asoc&amp;#39;s shutdown_last_sent_to is set to the transport<br /> that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually<br /> belongs to the new asoc. After the new_asoc is freed and the old asoc<br /> T2 timeout, the old asoc&amp;#39;s shutdown_last_sent_to that is already freed<br /> would be accessed in sctp_sf_t2_timer_expire().<br /> <br /> Thanks Alexander and Jere for helping dig into this issue.<br /> <br /> To fix it, this patch is to do the asoc update first, then allocate<br /> the COOKIE-ACK and SHUTDOWN chunks with the &amp;#39;updated&amp;#39; old asoc. This<br /> would make more sense, as a chunk from an asoc shouldn&amp;#39;t be sent out<br /> with another asoc. We had fixed quite a few issues caused by this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix inode leak on getattr error in __fh_to_dentry

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: Fix cwnd update ordering<br /> <br /> After a reconnect, the reply handler is opening the cwnd (and thus<br /> enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs()<br /> can post enough Receive WRs to receive their replies. This causes an<br /> RNR and the new connection is lost immediately.<br /> <br /> The race is most clearly exposed when KASAN and disconnect injection<br /> are enabled. This slows down rpcrdma_rep_create() enough to allow<br /> the send side to post a bunch of RPC Calls before the Receive<br /> completion handler can invoke ib_post_recv().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix null pointer dereference in svc_rqst_free()<br /> <br /> When alloc_pages_node() returns null in svc_rqst_alloc(), the<br /> null rq_scratch_page pointer will be dereferenced when calling<br /> put_page() in svc_rqst_free(). Fix it by adding a null check.<br /> <br /> Addresses-Coverity: ("Dereference after null check")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix potential null dereference on pointer status<br /> <br /> There are calls to idxd_cmd_exec that pass a null status pointer however<br /> a recent commit has added an assignment to *status that can end up<br /> with a null pointer dereference. The function expects a null status<br /> pointer sometimes as there is a later assignment to *status where<br /> status is first null checked. Fix the issue by null checking status<br /> before making the assignment.<br /> <br /> Addresses-Coverity: ("Explicit null dereferenced")