Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: be a bit more careful in checking for NULL bdev while polling<br /> <br /> Wei reports a crash with an application using polled IO:<br /> <br /> PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1<br /> Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022<br /> RIP: 0010:bio_poll+0x25/0x200<br /> Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65<br /> RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600<br /> RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140<br /> RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00<br /> R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001<br /> FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> iocb_bio_iopoll+0x1d/0x30<br /> io_do_iopoll+0xac/0x250<br /> __se_sys_io_uring_enter+0x3c5/0x5a0<br /> ? __x64_sys_write+0x89/0xd0<br /> do_syscall_64+0x2d/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x94f225d<br /> Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7<br /> RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa<br /> RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007<br /> RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000<br /> <br /> which is due to bio-&gt;bi_bdev being NULL. This can happen if we have two<br /> tasks doing polled IO, and task B ends up completing IO from task A if<br /> they are sharing a poll queue. If task B completes the IO and puts the<br /> bio into our cache, then it can allocate that bio again before task A<br /> is done polling for it. As that would necessitate a preempt between the<br /> two tasks, it&amp;#39;s enough to just be a bit more careful in checking for<br /> whether or not bio-&gt;bi_bdev is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Check scheduler work queue before calling timeout handling<br /> <br /> During an IGT GPU reset test we see again oops despite of<br /> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling<br /> timeout handling).<br /> <br /> It uses ready condition whether to call drm_sched_fault which unwind<br /> the TDR leads to GPU reset.<br /> However it looks the ready condition is overloaded with other meanings,<br /> for example, for the following stack is related GPU reset :<br /> <br /> 0 gfx_v9_0_cp_gfx_start<br /> 1 gfx_v9_0_cp_gfx_resume<br /> 2 gfx_v9_0_cp_resume<br /> 3 gfx_v9_0_hw_init<br /> 4 gfx_v9_0_resume<br /> 5 amdgpu_device_ip_resume_phase2<br /> <br /> does the following:<br /> /* start the ring */<br /> gfx_v9_0_cp_gfx_start(adev);<br /> ring-&gt;sched.ready = true;<br /> <br /> The same approach is for other ASICs as well :<br /> gfx_v8_0_cp_gfx_resume<br /> gfx_v10_0_kiq_resume, etc...<br /> <br /> As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault<br /> and then drm_sched_fault. However now it depends on whether the interrupt service routine<br /> drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready<br /> field of the scheduler to true even for uninitialized schedulers and causes oops vs<br /> no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and<br /> NULL pointer dereference does not occur.<br /> <br /> Use the field timeout_wq to prevent oops for uninitialized schedulers.<br /> The field could be initialized by the work queue of resetting the domain.<br /> <br /> v1: Corrections to commit message (Luben)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: check null pointer before accessing when swapping<br /> <br /> Add a check to avoid null pointer dereference as below:<br /> <br /> [ 90.002283] general protection fault, probably for non-canonical<br /> address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [ 90.002292] KASAN: null-ptr-deref in range<br /> [0x0000000000000000-0x0000000000000007]<br /> [ 90.002346] ? exc_general_protection+0x159/0x240<br /> [ 90.002352] ? asm_exc_general_protection+0x26/0x30<br /> [ 90.002357] ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm]<br /> [ 90.002365] ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm]<br /> [ 90.002373] ttm_bo_swapout+0x134/0x7f0 [ttm]<br /> [ 90.002383] ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm]<br /> [ 90.002391] ? lock_acquire+0x44d/0x4f0<br /> [ 90.002398] ? ttm_device_swapout+0xa5/0x260 [ttm]<br /> [ 90.002412] ? lock_acquired+0x355/0xa00<br /> [ 90.002416] ? do_raw_spin_trylock+0xb6/0x190<br /> [ 90.002421] ? __pfx_lock_acquired+0x10/0x10<br /> [ 90.002426] ? ttm_global_swapout+0x25/0x210 [ttm]<br /> [ 90.002442] ttm_device_swapout+0x198/0x260 [ttm]<br /> [ 90.002456] ? __pfx_ttm_device_swapout+0x10/0x10 [ttm]<br /> [ 90.002472] ttm_global_swapout+0x75/0x210 [ttm]<br /> [ 90.002486] ttm_tt_populate+0x187/0x3f0 [ttm]<br /> [ 90.002501] ttm_bo_handle_move_mem+0x437/0x590 [ttm]<br /> [ 90.002517] ttm_bo_validate+0x275/0x430 [ttm]<br /> [ 90.002530] ? __pfx_ttm_bo_validate+0x10/0x10 [ttm]<br /> [ 90.002544] ? kasan_save_stack+0x33/0x60<br /> [ 90.002550] ? kasan_set_track+0x25/0x30<br /> [ 90.002554] ? __kasan_kmalloc+0x8f/0xa0<br /> [ 90.002558] ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu]<br /> [ 90.003023] ? ttm_resource_alloc+0xf6/0x220 [ttm]<br /> [ 90.003038] amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu]<br /> [ 90.003210] ? __x64_sys_ioctl+0x131/0x1a0<br /> [ 90.003210] ? do_syscall_64+0x60/0x90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()<br /> <br /> The memory manager IDR is currently destroyed when user releases the<br /> file descriptor.<br /> However, at this point the user context might be still held, and memory<br /> buffers might be still in use.<br /> Later on, calls to release those buffers will fail due to not finding<br /> their handles in the IDR, leading to a memory leak.<br /> To avoid this leak, split the IDR destruction from the memory manager<br /> fini, and postpone it to hpriv_release() when there is no user context<br /> and no buffers are used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: skb_segment, Call zero copy functions before using skbuff frags<br /> <br /> Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions<br /> once per nskb") added the call to zero copy functions in skb_segment().<br /> The change introduced a bug in skb_segment() because skb_orphan_frags()<br /> may possibly change the number of fragments or allocate new fragments<br /> altogether leaving nrfrags and frag to point to the old values. This can<br /> cause a panic with stacktrace like the one below.<br /> <br /> [ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc<br /> [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26<br /> [ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0<br /> [ 194.021892] Call Trace:<br /> [ 194.027422] <br /> [ 194.072861] tcp_gso_segment+0x107/0x540<br /> [ 194.082031] inet_gso_segment+0x15c/0x3d0<br /> [ 194.090783] skb_mac_gso_segment+0x9f/0x110<br /> [ 194.095016] __skb_gso_segment+0xc1/0x190<br /> [ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem]<br /> [ 194.107071] dev_qdisc_enqueue+0x16/0x70<br /> [ 194.110884] __dev_queue_xmit+0x63b/0xb30<br /> [ 194.121670] bond_start_xmit+0x159/0x380 [bonding]<br /> [ 194.128506] dev_hard_start_xmit+0xc3/0x1e0<br /> [ 194.131787] __dev_queue_xmit+0x8a0/0xb30<br /> [ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan]<br /> [ 194.141477] dev_hard_start_xmit+0xc3/0x1e0<br /> [ 194.144622] sch_direct_xmit+0xe3/0x280<br /> [ 194.147748] __dev_queue_xmit+0x54a/0xb30<br /> [ 194.154131] tap_get_user+0x2a8/0x9c0 [tap]<br /> [ 194.157358] tap_sendmsg+0x52/0x8e0 [tap]<br /> [ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net]<br /> [ 194.173631] handle_tx+0xcd/0xe0 [vhost_net]<br /> [ 194.176959] vhost_worker+0x76/0xb0 [vhost]<br /> [ 194.183667] kthread+0x118/0x140<br /> [ 194.190358] ret_from_fork+0x1f/0x30<br /> [ 194.193670] <br /> <br /> In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags<br /> local variable in skb_segment() stale. This resulted in the code hitting<br /> i &gt;= nrfrags prematurely and trying to move to next frag_skb using<br /> list_skb pointer, which was NULL, and caused kernel panic. Move the call<br /> to zero copy functions before using frags and nr_frags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: pi433: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once. This requires saving off the root directory dentry to make<br /> creation of individual device subdirectories easier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Add null pointer check in gserial_suspend<br /> <br /> Consider a case where gserial_disconnect has already cleared<br /> gser-&gt;ioport. And if gserial_suspend gets called afterwards,<br /> it will lead to accessing of gser-&gt;ioport and thus causing<br /> null pointer dereference.<br /> <br /> Avoid this by adding a null pointer check. Added a static<br /> spinlock to prevent gser-&gt;ioport from becoming null after<br /> the newly added null pointer check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: check slab-out-of-bounds in md_bitmap_get_counter<br /> <br /> If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()<br /> will return -EINVAL because &amp;#39;page &gt;= bitmap-&gt;pages&amp;#39;, but the return value<br /> was not checked immediately in md_bitmap_get_counter() in order to set<br /> *blocks value and slab-out-of-bounds occurs.<br /> <br /> Move check of &amp;#39;page &gt;= bitmap-&gt;pages&amp;#39; to md_bitmap_get_counter() and<br /> return directly if true.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix racy issue under cocurrent smb2 tree disconnect<br /> <br /> There is UAF issue under cocurrent smb2 tree disconnect.<br /> This patch introduce TREE_CONN_EXPIRE flags for tcon to avoid cocurrent<br /> access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp6: Fix null-ptr-deref of ip6_null_entry-&gt;rt6i_idev in icmp6_dev().<br /> <br /> With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that<br /> has the link-local address as src and dst IP and will be forwarded to<br /> an external IP in the IPv6 Ext Hdr.<br /> <br /> For example, the script below generates a packet whose src IP is the<br /> link-local address and dst is updated to 11::.<br /> <br /> # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 &gt; $f; done<br /> # python3<br /> &gt;&gt;&gt; from socket import *<br /> &gt;&gt;&gt; from scapy.all import *<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456"<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR)<br /> &gt;&gt;&gt; pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1)<br /> &gt;&gt;&gt;<br /> &gt;&gt;&gt; sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)<br /> &gt;&gt;&gt; sk.sendto(bytes(pkt), (DST_ADDR, 0))<br /> <br /> For such a packet, we call ip6_route_input() to look up a route for the<br /> next destination in these three functions depending on the header type.<br /> <br /> * ipv6_rthdr_rcv()<br /> * ipv6_rpl_srh_rcv()<br /> * ipv6_srh_rcv()<br /> <br /> If no route is found, ip6_null_entry is set to skb, and the following<br /> dst_input(skb) calls ip6_pkt_drop().<br /> <br /> Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)-&gt;rt6i_idev-&gt;dev<br /> as the input device is the loopback interface. Then, we have to check if<br /> skb_rt6_info(skb)-&gt;rt6i_idev is NULL or not to avoid NULL pointer deref<br /> for ip6_null_entry.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)<br /> Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01<br /> RSP: 0018:ffffc90000003c70 EFLAGS: 00000286<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0<br /> RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18<br /> RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10<br /> R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0<br /> FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ip6_pkt_drop (net/ipv6/route.c:4513)<br /> ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5))<br /> ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483)<br /> __netif_receive_skb_one_core (net/core/dev.c:5455)<br /> process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895)<br /> __napi_poll (net/core/dev.c:6460)<br /> net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)<br /> do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:381)<br /> __dev_queue_xmit (net/core/dev.c:4231)<br /> ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135)<br /> rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914)<br /> sock_sendmsg (net/socket.c:725 net/socket.c:748)<br /> __sys_sendto (net/socket.c:2134)<br /> __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> RIP: 0033:0x7f9dc751baea<br /> Code: d8 64 89 02 48 c7 c0 ff f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write<br /> <br /> Syzkaller reported the following issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]<br /> BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600<br /> aio_rw_done fs/aio.c:1520 [inline]<br /> aio_write+0x899/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc+0x11d/0x3b0 mm/slab_common.c:981<br /> kmalloc_array include/linux/slab.h:636 [inline]<br /> bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930<br /> bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> sock_write_iter+0x495/0x5e0 net/socket.c:1108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023<br /> =====================================================<br /> <br /> We can follow the call chain and find that &amp;#39;bcm_tx_setup&amp;#39; function<br /> calls &amp;#39;memcpy_from_msg&amp;#39; to copy some content to the newly allocated<br /> frame of &amp;#39;op-&gt;frames&amp;#39;. After that the &amp;#39;len&amp;#39; field of copied structure<br /> being compared with some constant value (64 or 8). However, if<br /> &amp;#39;memcpy_from_msg&amp;#39; returns an error, we will compare some uninitialized<br /> memory. This triggers &amp;#39;uninit-value&amp;#39; issue.<br /> <br /> This patch will add &amp;#39;memcpy_from_msg&amp;#39; possible errors processing to<br /> avoid uninit-value issue.<br /> <br /> Tested via syzkaller

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()<br /> <br /> Inside the loop in rxrpc_wait_to_be_connected() it checks call-&gt;error to<br /> see if it should exit the loop without first checking the call state. This<br /> is probably safe as if call-&gt;error is set, the call is dead anyway, but we<br /> should probably wait for the call state to have been set to completion<br /> first, lest it cause surprise on the way out.<br /> <br /> Fix this by only accessing call-&gt;error if the call is complete. We don&amp;#39;t<br /> actually need to access the error inside the loop as we&amp;#39;ll do that after.<br /> <br /> This caused the following report:<br /> <br /> BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion<br /> <br /> write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:<br /> rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22<br /> rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479<br /> rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714<br /> rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]<br /> rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350<br /> rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464<br /> rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461<br /> kthread+0x1ac/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:<br /> rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296<br /> rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726<br /> rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501<br /> ___sys_sendmsg net/socket.c:2555 [inline]<br /> __sys_sendmmsg+0x263/0x500 net/socket.c:2641<br /> __do_sys_sendmmsg net/socket.c:2670 [inline]<br /> __se_sys_sendmmsg net/socket.c:2667 [inline]<br /> __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x00000000 -&gt; 0xffffffea