Vulnerabilities

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")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid touching checkpointed data in get_victim()<br /> <br /> In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR<br /> mode to select victim:<br /> <br /> 1. LFS is set to find source section during GC, the victim should have<br /> no checkpointed data, since after GC, section could not be set free for<br /> reuse.<br /> <br /> Previously, we only check valid chpt blocks in current segment rather<br /> than section, fix it.<br /> <br /> 2. SSR | AT_SSR are set to find target segment for writes which can be<br /> fully filled by checkpointed and newly written blocks, we should never<br /> select such segment, otherwise it can cause panic or data corruption<br /> during allocation, potential case is described as below:<br /> <br /> a) target segment has &amp;#39;n&amp;#39; (n

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix NULL pointer dereference for -&gt;get_features()<br /> <br /> get_features ops of pci_epc_ops may return NULL, causing NULL pointer<br /> dereference in pci_epf_test_alloc_space function. Let us add a check for<br /> pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid<br /> any such NULL pointer dereference and return -ENOTSUPP in case<br /> pci_epc_feature is not found.<br /> <br /> When the patch is not applied and EPC features is not implemented in the<br /> platform driver, we see the following dump due to kernel NULL pointer<br /> dereference.<br /> <br /> Call trace:<br /> pci_epf_test_bind+0xf4/0x388<br /> pci_epf_bind+0x3c/0x80<br /> pci_epc_epf_link+0xa8/0xcc<br /> configfs_symlink+0x1a4/0x48c<br /> vfs_symlink+0x104/0x184<br /> do_symlinkat+0x80/0xd4<br /> __arm64_sys_symlinkat+0x1c/0x24<br /> el0_svc_common.constprop.3+0xb8/0x170<br /> el0_svc_handler+0x70/0x88<br /> el0_svc+0x8/0x640<br /> Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400)<br /> ---[ end trace a438e3c5a24f9df0 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9064/1: hw_breakpoint: Do not directly check the event&amp;#39;s overflow_handler hook<br /> <br /> The commit 1879445dfa7b ("perf/core: Set event&amp;#39;s default<br /> ::overflow_handler()") set a default event-&gt;overflow_handler in<br /> perf_event_alloc(), and replace the check event-&gt;overflow_handler with<br /> is_default_overflow_handler(), but one is missing.<br /> <br /> Currently, the bp-&gt;overflow_handler can not be NULL. As a result,<br /> enable_single_step() is always not invoked.<br /> <br /> Comments from Zhen Lei:<br /> <br /> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/