Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: systemport: Add global locking for descriptor lifecycle<br /> <br /> The descriptor list is a shared resource across all of the transmit queues, and<br /> the locking mechanism used today only protects concurrency across a given<br /> transmit queue between the transmit and reclaiming. This creates an opportunity<br /> for the SYSTEMPORT hardware to work on corrupted descriptors if we have<br /> multiple producers at once which is the case when using multiple transmit<br /> queues.<br /> <br /> This was particularly noticeable when using multiple flows/transmit queues and<br /> it showed up in interesting ways in that UDP packets would get a correct UDP<br /> header checksum being calculated over an incorrect packet length. Similarly TCP<br /> packets would get an equally correct checksum computed by the hardware over an<br /> incorrect packet length.<br /> <br /> The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges<br /> when the driver produces a new descriptor anytime it writes to the<br /> WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to<br /> re-organize its descriptors and it is possible that concurrent TX queues<br /> eventually break this internal allocation scheme to the point where the<br /> length/status part of the descriptor gets used for an incorrect data buffer.<br /> <br /> The fix is to impose a global serialization for all TX queues in the short<br /> section where we are writing to the WRITE_PORT_{HI,LO} registers which solves<br /> the corruption even with multiple concurrent TX queues being used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sit: do not call ipip6_dev_free() from sit_init_net()<br /> <br /> ipip6_dev_free is sit dev-&gt;priv_destructor, already called<br /> by register_netdevice() if something goes wrong.<br /> <br /> Alternative would be to make ipip6_dev_free() robust against<br /> multiple invocations, but other drivers do not implement this<br /> strategy.<br /> <br /> syzbot reported:<br /> <br /> dst_release underflow<br /> WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173<br /> Modules linked in:<br /> CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173<br /> Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48<br /> RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246<br /> RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000<br /> RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000<br /> RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c<br /> R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358<br /> R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000<br /> FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160<br /> ipip6_dev_free net/ipv6/sit.c:1414 [inline]<br /> sit_init_net+0x229/0x550 net/ipv6/sit.c:1936<br /> ops_init+0x313/0x430 net/core/net_namespace.c:140<br /> setup_net+0x35b/0x9d0 net/core/net_namespace.c:326<br /> copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470<br /> create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226<br /> ksys_unshare+0x57d/0xb50 kernel/fork.c:3075<br /> __do_sys_unshare kernel/fork.c:3146 [inline]<br /> __se_sys_unshare kernel/fork.c:3144 [inline]<br /> __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f66c882ce99<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200<br /> RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igbvf: fix double free in `igbvf_probe`<br /> <br /> In `igbvf_probe`, if register_netdev() fails, the program will go to<br /> label err_hw_init, and then to label err_ioremap. In free_netdev() which<br /> is just below label err_ioremap, there is `list_for_each_entry_safe` and<br /> `netif_napi_del` which aims to delete all entries in `dev-&gt;napi_list`.<br /> The program has added an entry `adapter-&gt;rx_ring-&gt;napi` which is added by<br /> `netif_napi_add` in igbvf_alloc_queues(). However, adapter-&gt;rx_ring has<br /> been freed below label err_hw_init. So this a UAF.<br /> <br /> In terms of how to patch the problem, we can refer to igbvf_remove() and<br /> delete the entry before `adapter-&gt;rx_ring`.<br /> <br /> The KASAN logs are as follows:<br /> <br /> [ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450<br /> [ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366<br /> [ 35.128360]<br /> [ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14<br /> [ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> [ 35.131749] Call Trace:<br /> [ 35.132199] dump_stack_lvl+0x59/0x7b<br /> [ 35.132865] print_address_description+0x7c/0x3b0<br /> [ 35.133707] ? free_netdev+0x1fd/0x450<br /> [ 35.134378] __kasan_report+0x160/0x1c0<br /> [ 35.135063] ? free_netdev+0x1fd/0x450<br /> [ 35.135738] kasan_report+0x4b/0x70<br /> [ 35.136367] free_netdev+0x1fd/0x450<br /> [ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]<br /> [ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]<br /> [ 35.138751] local_pci_probe+0x13c/0x1f0<br /> [ 35.139461] pci_device_probe+0x37e/0x6c0<br /> [ 35.165526]<br /> [ 35.165806] Allocated by task 366:<br /> [ 35.166414] ____kasan_kmalloc+0xc4/0xf0<br /> [ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]<br /> [ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]<br /> [ 35.168866] local_pci_probe+0x13c/0x1f0<br /> [ 35.169565] pci_device_probe+0x37e/0x6c0<br /> [ 35.179713]<br /> [ 35.179993] Freed by task 366:<br /> [ 35.180539] kasan_set_track+0x4c/0x80<br /> [ 35.181211] kasan_set_free_info+0x1f/0x40<br /> [ 35.181942] ____kasan_slab_free+0x103/0x140<br /> [ 35.182703] kfree+0xe3/0x250<br /> [ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]<br /> [ 35.184040] local_pci_probe+0x13c/0x1f0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix deadlock in __mptcp_push_pending()<br /> <br /> __mptcp_push_pending() may call mptcp_flush_join_list() with subflow<br /> socket lock held. If such call hits mptcp_sockopt_sync_all() then<br /> subsequently __mptcp_sockopt_sync() could try to lock the subflow<br /> socket for itself, causing a deadlock.<br /> <br /> sysrq: Show Blocked State<br /> task:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000<br /> Call Trace:<br /> <br /> __schedule+0x2d6/0x10c0<br /> ? __mod_memcg_state+0x4d/0x70<br /> ? csum_partial+0xd/0x20<br /> ? _raw_spin_lock_irqsave+0x26/0x50<br /> schedule+0x4e/0xc0<br /> __lock_sock+0x69/0x90<br /> ? do_wait_intr_irq+0xa0/0xa0<br /> __lock_sock_fast+0x35/0x50<br /> mptcp_sockopt_sync_all+0x38/0xc0<br /> __mptcp_push_pending+0x105/0x200<br /> mptcp_sendmsg+0x466/0x490<br /> sock_sendmsg+0x57/0x60<br /> __sys_sendto+0xf0/0x160<br /> ? do_wait_intr_irq+0xa0/0xa0<br /> ? fpregs_restore_userregs+0x12/0xd0<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f9ba546c2d0<br /> RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0<br /> RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234<br /> RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060<br /> R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8<br /> <br /> <br /> Fix the issue by using __mptcp_flush_join_list() instead of plain<br /> mptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by<br /> Florian. The sockopt sync will be deferred to the workqueue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: remove tcp ulp setsockopt support<br /> <br /> TCP_ULP setsockopt cannot be used for mptcp because its already<br /> used internally to plumb subflow (tcp) sockets to the mptcp layer.<br /> <br /> syzbot managed to trigger a crash for mptcp connections that are<br /> in fallback mode:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]<br /> CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0<br /> RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline]<br /> [..]<br /> __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]<br /> tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160<br /> do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391<br /> mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638<br /> <br /> Remove support for TCP_ULP setsockopt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix tc flower deletion for VLAN priority Rx steering<br /> <br /> To replicate the issue:-<br /> <br /> 1) Add 1 flower filter for VLAN Priority based frame steering:-<br /> $ IFDEVNAME=eth0<br /> $ tc qdisc add dev $IFDEVNAME ingress<br /> $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \<br /> map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \<br /> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0<br /> $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \<br /> flower vlan_prio 0 hw_tc 0<br /> <br /> 2) Get the &amp;#39;pref&amp;#39; id<br /> $ tc filter show dev $IFDEVNAME ingress<br /> <br /> 3) Delete a specific tc flower record (say pref 49151)<br /> $ tc filter del dev $IFDEVNAME parent ffff: pref 49151<br /> <br /> From dmesg, we will observe kernel NULL pointer ooops<br /> <br /> [ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 197.171367] #PF: supervisor read access in kernel mode<br /> [ 197.171367] #PF: error_code(0x0000) - not-present page<br /> [ 197.171367] PGD 0 P4D 0<br /> [ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> <br /> <br /> <br /> [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]<br /> <br /> <br /> <br /> [ 197.171367] Call Trace:<br /> [ 197.171367] <br /> [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]<br /> [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]<br /> [ 197.171367] tc_setup_cb_destroy+0xb3/0x180<br /> [ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]<br /> <br /> The above issue is due to previous incorrect implementation of<br /> tc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()<br /> to get struct flow_rule *rule which is no longer valid for tc filter<br /> delete operation.<br /> <br /> struct flow_rule *rule = flow_cls_offload_flow_rule(cls);<br /> struct flow_dissector *dissector = rule-&gt;match.dissector;<br /> <br /> So, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for<br /> earlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),<br /> this patch introduces stmmac_rfs_entry as driver-side flow_cls_offload<br /> record for &amp;#39;RX frame steering&amp;#39; tc flower, currently used for VLAN<br /> priority. The implementation has taken consideration for future extension<br /> to include other type RX frame steering such as EtherType based.<br /> <br /> v2:<br /> - Clean up overly extensive backtrace and rewrite git message to better<br /> explain the kernel NULL pointer issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: clear &amp;#39;kern&amp;#39; flag from fallback sockets<br /> <br /> The mptcp ULP extension relies on sk-&gt;sk_sock_kern being set correctly:<br /> It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); from<br /> working for plain tcp sockets (any userspace-exposed socket).<br /> <br /> But in case of fallback, accept() can return a plain tcp sk.<br /> In such case, sk is still tagged as &amp;#39;kernel&amp;#39; and setsockopt will work.<br /> <br /> This will crash the kernel, The subflow extension has a NULL ctx-&gt;conn<br /> mptcp socket:<br /> <br /> BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0<br /> Call Trace:<br /> tcp_data_ready+0xf8/0x370<br /> [..]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: never allow the PM to close a listener subflow<br /> <br /> Currently, when deleting an endpoint the netlink PM treverses<br /> all the local MPTCP sockets, regardless of their status.<br /> <br /> If an MPTCP listener socket is bound to the IP matching the<br /> delete endpoint, the listener TCP socket will be closed.<br /> That is unexpected, the PM should only affect data subflows.<br /> <br /> Additionally, syzbot was able to trigger a NULL ptr dereference<br /> due to the above:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897<br /> Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff<br /> RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016<br /> RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000<br /> RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000<br /> R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001<br /> FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> lock_acquire kernel/locking/lockdep.c:5637 [inline]<br /> lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162<br /> finish_wait+0xc0/0x270 kernel/sched/wait.c:400<br /> inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]<br /> inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497<br /> mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865<br /> inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739<br /> mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345<br /> do_accept+0x382/0x510 net/socket.c:1773<br /> __sys_accept4_file+0x7e/0xe0 net/socket.c:1816<br /> __sys_accept4+0xb0/0x100 net/socket.c:1846<br /> __do_sys_accept net/socket.c:1864 [inline]<br /> __se_sys_accept net/socket.c:1861 [inline]<br /> __x64_sys_accept+0x71/0xb0 net/socket.c:1861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f177cd8b8e9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b<br /> RAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c<br /> R13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000<br /> <br /> <br /> Fix the issue explicitly skipping MPTCP socket in TCP_LISTEN<br /> status.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()<br /> <br /> In resp_mode_select() sanity check the block descriptor len to avoid UAF.<br /> <br /> BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> Read of size 1 at addr ffff888026670f50 by task scsicmd/15032<br /> <br /> CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257<br /> kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443<br /> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306<br /> resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509<br /> schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483<br /> scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537<br /> scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63<br /> sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837<br /> sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775<br /> sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: check for wq exit after adding new worker task_work<br /> <br /> We check IO_WQ_BIT_EXIT before attempting to create a new worker, and<br /> wq exit cancels pending work if we have any. But it&amp;#39;s possible to have<br /> a race between the two, where creation checks exit finding it not set,<br /> but we&amp;#39;re in the process of exiting. The exit side will cancel pending<br /> creation task_work, but there&amp;#39;s a gap where we add task_work after we&amp;#39;ve<br /> canceled existing creations at exit time.<br /> <br /> Fix this by checking the EXIT bit post adding the creation task_work.<br /> If it&amp;#39;s set, run the same cancelation that exit does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Don&amp;#39;t call kcalloc() if size arg is zero<br /> <br /> If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of<br /> that, for a following NULL pointer check to work on the returned pointer,<br /> kcalloc() must not be called with the size arg equal to zero. Return early<br /> without error before the kcalloc() call if size arg is zero.<br /> <br /> BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]<br /> BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> Write of size 4 at addr 0000000000000010 by task syz-executor.1/22789<br /> <br /> CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> __kasan_report mm/kasan/report.c:446 [inline]<br /> kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189<br /> memcpy+0x3b/0x60 mm/kasan/shadow.c:66<br /> memcpy include/linux/fortify-string.h:191 [inline]<br /> sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]<br /> do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]<br /> resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276<br /> schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478<br /> scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533<br /> scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]<br /> scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699<br /> blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639<br /> __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325<br /> blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358<br /> __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761<br /> __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838<br /> blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891<br /> blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474<br /> blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62<br /> blk_execute_rq+0xdb/0x360 block/blk-exec.c:102<br /> sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]<br /> scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930<br /> sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112<br /> sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae