Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: veth: clear GRO when clearing XDP even when down<br /> <br /> veth sets NETIF_F_GRO automatically when XDP is enabled,<br /> because both features use the same NAPI machinery.<br /> <br /> The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which<br /> is called both on ndo_stop and when XDP is turned off.<br /> To avoid the flag from being cleared when the device is brought<br /> down, the clearing is skipped when IFF_UP is not set.<br /> Bringing the device down should indeed not modify its features.<br /> <br /> Unfortunately, this means that clearing is also skipped when<br /> XDP is disabled _while_ the device is down. And there&amp;#39;s nothing<br /> on the open path to bring the device features back into sync.<br /> IOW if user enables XDP, disables it and then brings the device<br /> up we&amp;#39;ll end up with a stray GRO flag set but no NAPI instances.<br /> <br /> We don&amp;#39;t depend on the GRO flag on the datapath, so the datapath<br /> won&amp;#39;t crash. We will crash (or hang), however, next time features<br /> are sync&amp;#39;ed (either by user via ethtool or peer changing its config).<br /> The GRO flag will go away, and veth will try to disable the NAPIs.<br /> But the open path never created them since XDP was off, the GRO flag<br /> was a stray. If NAPI was initialized before we&amp;#39;ll hang in napi_disable().<br /> If it never was we&amp;#39;ll crash trying to stop uninitialized hrtimer.<br /> <br /> Move the GRO flag updates to the XDP enable / disable paths,<br /> instead of mixing them with the ndo_open / ndo_close paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ip_tunnel: prevent perpetual headroom growth<br /> <br /> syzkaller triggered following kasan splat:<br /> BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170<br /> Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191<br /> [..]<br /> kasan_report+0xda/0x110 mm/kasan/report.c:588<br /> __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170<br /> skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]<br /> ___skb_get_hash net/core/flow_dissector.c:1791 [inline]<br /> __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856<br /> skb_get_hash include/linux/skbuff.h:1556 [inline]<br /> ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748<br /> ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308<br /> __netdev_start_xmit include/linux/netdevice.h:4940 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4954 [inline]<br /> xmit_one net/core/dev.c:3548 [inline]<br /> dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564<br /> __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349<br /> dev_queue_xmit include/linux/netdevice.h:3134 [inline]<br /> neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592<br /> ...<br /> ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235<br /> ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323<br /> ..<br /> iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82<br /> ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831<br /> ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665<br /> __netdev_start_xmit include/linux/netdevice.h:4940 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4954 [inline]<br /> xmit_one net/core/dev.c:3548 [inline]<br /> dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564<br /> ...<br /> <br /> The splat occurs because skb-&gt;data points past skb-&gt;head allocated area.<br /> This is because neigh layer does:<br /> __skb_pull(skb, skb_network_offset(skb));<br /> <br /> ... but skb_network_offset() returns a negative offset and __skb_pull()<br /> arg is unsigned. IOW, we skb-&gt;data gets "adjusted" by a huge value.<br /> <br /> The negative value is returned because skb-&gt;head and skb-&gt;data distance is<br /> more than 64k and skb-&gt;network_header (u16) has wrapped around.<br /> <br /> The bug is in the ip_tunnel infrastructure, which can cause<br /> dev-&gt;needed_headroom to increment ad infinitum.<br /> <br /> The syzkaller reproducer consists of packets getting routed via a gre<br /> tunnel, and route of gre encapsulated packets pointing at another (ipip)<br /> tunnel. The ipip encapsulation finds gre0 as next output device.<br /> <br /> This results in the following pattern:<br /> <br /> 1). First packet is to be sent out via gre0.<br /> Route lookup found an output device, ipip0.<br /> <br /> 2).<br /> ip_tunnel_xmit for gre0 bumps gre0-&gt;needed_headroom based on the future<br /> output device, rt.dev-&gt;needed_headroom (ipip0).<br /> <br /> 3).<br /> ip output / start_xmit moves skb on to ipip0. which runs the same<br /> code path again (xmit recursion).<br /> <br /> 4).<br /> Routing step for the post-gre0-encap packet finds gre0 as output device<br /> to use for ipip0 encapsulated packet.<br /> <br /> tunl0-&gt;needed_headroom is then incremented based on the (already bumped)<br /> gre0 device headroom.<br /> <br /> This repeats for every future packet:<br /> <br /> gre0-&gt;needed_headroom gets inflated because previous packets&amp;#39; ipip0 step<br /> incremented rt-&gt;dev (gre0) headroom, and ipip0 incremented because gre0<br /> needed_headroom was increased.<br /> <br /> For each subsequent packet, gre/ipip0-&gt;needed_headroom grows until<br /> post-expand-head reallocations result in a skb-&gt;head/data distance of<br /> more than 64k.<br /> <br /> Once that happens, skb-&gt;network_header (u16) wraps around when<br /> pskb_expand_head tries to make sure that skb_network_offset() is unchanged<br /> after the headroom expansion/reallocation.<br /> <br /> After this skb_network_offset(skb) returns a different (and negative)<br /> result post headroom expansion.<br /> <br /> The next trip to neigh layer (or anything else that would __skb_pull the<br /> network header) makes skb-&gt;data point to a memory location outside<br /> skb-&gt;head area.<br /> <br /> v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to<br /> prevent perpetual increase instead of dropping the headroom increment<br /> completely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter<br /> <br /> syzbot reported the following uninit-value access issue [1]:<br /> <br /> netlink_to_full_skb() creates a new `skb` and puts the `skb-&gt;data`<br /> passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data<br /> size is specified as `len` and passed to skb_put_data(). This `len`<br /> is based on `skb-&gt;end` that is not data offset but buffer offset. The<br /> `skb-&gt;end` contains data and tailroom. Since the tailroom is not<br /> initialized when the new `skb` created, KMSAN detects uninitialized<br /> memory area when copying the data.<br /> <br /> This patch resolved this issue by correct the len from `skb-&gt;end` to<br /> `skb-&gt;len`, which is the actual data offset.<br /> <br /> BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186<br /> copy_to_iter include/linux/uio.h:197 [inline]<br /> simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532<br /> __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420<br /> skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546<br /> skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]<br /> packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482<br /> sock_recvmsg_nosec net/socket.c:1044 [inline]<br /> sock_recvmsg net/socket.c:1066 [inline]<br /> sock_read_iter+0x467/0x580 net/socket.c:1136<br /> call_read_iter include/linux/fs.h:2014 [inline]<br /> new_sync_read fs/read_write.c:389 [inline]<br /> vfs_read+0x8f6/0xe00 fs/read_write.c:470<br /> ksys_read+0x20f/0x4c0 fs/read_write.c:613<br /> __do_sys_read fs/read_write.c:623 [inline]<br /> __se_sys_read fs/read_write.c:621 [inline]<br /> __x64_sys_read+0x93/0xd0 fs/read_write.c:621<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was stored to memory at:<br /> skb_put_data include/linux/skbuff.h:2622 [inline]<br /> netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]<br /> __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]<br /> __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325<br /> netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]<br /> netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368<br /> netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638<br /> __sys_sendmsg net/socket.c:2667 [inline]<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> free_pages_prepare mm/page_alloc.c:1087 [inline]<br /> free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347<br /> free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533<br /> release_pages+0x23d3/0x2410 mm/swap.c:1042<br /> free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316<br /> tlb_batch_pages<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks<br /> <br /> The -&gt;runtime_suspend() and -&gt;runtime_resume() callbacks are not<br /> expected to call spi_controller_suspend() and spi_controller_resume().<br /> Remove calls to those in the cadence-qspi driver.<br /> <br /> Those helpers have two roles currently:<br /> - They stop/start the queue, including dealing with the kworker.<br /> - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It<br /> requires acquiring ctlr-&gt;bus_lock_mutex.<br /> <br /> Step one is irrelevant because cadence-qspi is not queued. Step two<br /> however has two implications:<br /> - A deadlock occurs, because -&gt;runtime_resume() is called in a context<br /> where the lock is already taken (in the -&gt;exec_op() callback, where<br /> the usage count is incremented).<br /> - It would disallow all operations once the device is auto-suspended.<br /> <br /> Here is a brief call tree highlighting the mutex deadlock:<br /> <br /> spi_mem_exec_op()<br /> ...<br /> spi_mem_access_start()<br /> mutex_lock(&amp;ctlr-&gt;bus_lock_mutex)<br /> <br /> cqspi_exec_mem_op()<br /> pm_runtime_resume_and_get()<br /> cqspi_resume()<br /> spi_controller_resume()<br /> mutex_lock(&amp;ctlr-&gt;bus_lock_mutex)<br /> ...<br /> <br /> spi_mem_access_end()<br /> mutex_unlock(&amp;ctlr-&gt;bus_lock_mutex)<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Both cadence-quadspi -&gt;runtime_suspend() and -&gt;runtime_resume()<br /> implementations start with:<br /> <br /> struct cqspi_st *cqspi = dev_get_drvdata(dev);<br /> struct spi_controller *host = dev_get_drvdata(dev);<br /> <br /> This obviously cannot be correct, unless "struct cqspi_st" is the<br /> first member of " struct spi_controller", or the other way around, but<br /> it is not the case. "struct spi_controller" is allocated by<br /> devm_spi_alloc_host(), which allocates an extra amount of memory for<br /> private data, used to store "struct cqspi_st".<br /> <br /> The -&gt;probe() function of the cadence-quadspi driver then sets the<br /> device drvdata to store the address of the "struct cqspi_st"<br /> structure. Therefore:<br /> <br /> struct cqspi_st *cqspi = dev_get_drvdata(dev);<br /> <br /> is correct, but:<br /> <br /> struct spi_controller *host = dev_get_drvdata(dev);<br /> <br /> is not, as it makes "host" point not to a "struct spi_controller" but<br /> to the same "struct cqspi_st" structure as above.<br /> <br /> This obviously leads to bad things (memory corruption, kernel crashes)<br /> directly during -&gt;probe(), as -&gt;probe() enables the device using PM<br /> runtime, leading the -&gt;runtime_resume() hook being called, which in<br /> turns calls spi_controller_resume() with the wrong pointer.<br /> <br /> This has at least been reported [0] to cause a kernel crash, but the<br /> exact behavior will depend on the memory contents.<br /> <br /> [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/<br /> <br /> This issue potentially affects all platforms that are currently using<br /> the cadence-quadspi driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix use-after-free on failed backlog decryption<br /> <br /> When the decrypt request goes to the backlog and crypto_aead_decrypt<br /> returns -EBUSY, tls_do_decryption will wait until all async<br /> decryptions have completed. If one of them fails, tls_do_decryption<br /> will return -EBADMSG and tls_decrypt_sg jumps to the error path,<br /> releasing all the pages. But the pages have been passed to the async<br /> callback, and have already been released by tls_decrypt_done.<br /> <br /> The only true async case is when crypto_aead_decrypt returns<br /> -EINPROGRESS. With -EBUSY, we already waited so we can tell<br /> tls_sw_recvmsg that the data is available for immediate copy, but we<br /> need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the<br /> memory has already been released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix double-free on socket dismantle<br /> <br /> when MPTCP server accepts an incoming connection, it clones its listener<br /> socket. However, the pointer to &amp;#39;inet_opt&amp;#39; for the new socket has the same<br /> value as the original one: as a consequence, on program exit it&amp;#39;s possible<br /> to observe the following splat:<br /> <br /> BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0<br /> Free of addr ffff888485950880 by task swapper/25/0<br /> <br /> CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609<br /> Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> print_report+0xca/0x620<br /> kasan_report_invalid_free+0x64/0x90<br /> __kasan_slab_free+0x1aa/0x1f0<br /> kfree+0xed/0x2e0<br /> inet_sock_destruct+0x54f/0x8b0<br /> __sk_destruct+0x48/0x5b0<br /> rcu_do_batch+0x34e/0xd90<br /> rcu_core+0x559/0xac0<br /> __do_softirq+0x183/0x5a4<br /> irq_exit_rcu+0x12d/0x170<br /> sysvec_apic_timer_interrupt+0x6b/0x80<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> RIP: 0010:cpuidle_enter_state+0x175/0x300<br /> Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b<br /> RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000<br /> RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588<br /> RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080<br /> R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0<br /> R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80<br /> cpuidle_enter+0x4a/0xa0<br /> do_idle+0x310/0x410<br /> cpu_startup_entry+0x51/0x60<br /> start_secondary+0x211/0x270<br /> secondary_startup_64_no_verify+0x184/0x18b<br /> <br /> <br /> Allocated by task 6853:<br /> kasan_save_stack+0x1c/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0xa6/0xb0<br /> __kmalloc+0x1eb/0x450<br /> cipso_v4_sock_setattr+0x96/0x360<br /> netlbl_sock_setattr+0x132/0x1f0<br /> selinux_netlbl_socket_post_create+0x6c/0x110<br /> selinux_socket_post_create+0x37b/0x7f0<br /> security_socket_post_create+0x63/0xb0<br /> __sock_create+0x305/0x450<br /> __sys_socket_create.part.23+0xbd/0x130<br /> __sys_socket+0x37/0xb0<br /> __x64_sys_socket+0x6f/0xb0<br /> do_syscall_64+0x83/0x160<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Freed by task 6858:<br /> kasan_save_stack+0x1c/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x12c/0x1f0<br /> kfree+0xed/0x2e0<br /> inet_sock_destruct+0x54f/0x8b0<br /> __sk_destruct+0x48/0x5b0<br /> subflow_ulp_release+0x1f0/0x250<br /> tcp_cleanup_ulp+0x6e/0x110<br /> tcp_v4_destroy_sock+0x5a/0x3a0<br /> inet_csk_destroy_sock+0x135/0x390<br /> tcp_fin+0x416/0x5c0<br /> tcp_data_queue+0x1bc8/0x4310<br /> tcp_rcv_state_process+0x15a3/0x47b0<br /> tcp_v4_do_rcv+0x2c1/0x990<br /> tcp_v4_rcv+0x41fb/0x5ed0<br /> ip_protocol_deliver_rcu+0x6d/0x9f0<br /> ip_local_deliver_finish+0x278/0x360<br /> ip_local_deliver+0x182/0x2c0<br /> ip_rcv+0xb5/0x1c0<br /> __netif_receive_skb_one_core+0x16e/0x1b0<br /> process_backlog+0x1e3/0x650<br /> __napi_poll+0xa6/0x500<br /> net_rx_action+0x740/0xbb0<br /> __do_softirq+0x183/0x5a4<br /> <br /> The buggy address belongs to the object at ffff888485950880<br /> which belongs to the cache kmalloc-64 of size 64<br /> The buggy address is located 0 bytes inside of<br /> 64-byte region [ffff888485950880, ffff8884859508c0)<br /> <br /> The buggy address belongs to the physical page:<br /> page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950<br /> flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)<br /> page_type: 0xffffffff()<br /> raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006<br /> raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888485950780: fa fb fb<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: arm: Fix NULL dereference on scmi_perf_domain removal<br /> <br /> On unloading of the scmi_perf_domain module got the below splat, when in<br /> the DT provided to the system under test the &amp;#39;#power-domain-cells&amp;#39; property<br /> was missing. Indeed, this particular setup causes the probe to bail out<br /> early without giving any error, which leads to the -&gt;remove() callback gets<br /> to run too, but without all the expected initialized structures in place.<br /> <br /> Add a check and bail out early on remove too.<br /> <br /> Call trace:<br /> scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain]<br /> scmi_dev_remove+0x28/0x40 [scmi_core]<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1dc/0x240<br /> driver_detach+0x58/0xa8<br /> bus_remove_driver+0x78/0x108<br /> driver_unregister+0x38/0x70<br /> scmi_driver_unregister+0x28/0x180 [scmi_core]<br /> scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain]<br /> __arm64_sys_delete_module+0x1a8/0x2c0<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x34/0xb8<br /> el0t_64_sync_handler+0x100/0x130<br /> el0t_64_sync+0x190/0x198<br /> Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix protection fault in iommufd_test_syz_conv_iova<br /> <br /> Syzkaller reported the following bug:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7]<br /> Call Trace:<br /> lock_acquire<br /> lock_acquire+0x1ce/0x4f0<br /> down_read+0x93/0x4a0<br /> iommufd_test_syz_conv_iova+0x56/0x1f0<br /> iommufd_test_access_rw.isra.0+0x2ec/0x390<br /> iommufd_test+0x1058/0x1e30<br /> iommufd_fops_ioctl+0x381/0x510<br /> vfs_ioctl<br /> __do_sys_ioctl<br /> __se_sys_ioctl<br /> __x64_sys_ioctl+0x170/0x1e0<br /> do_syscall_x64<br /> do_syscall_64+0x71/0x140<br /> <br /> This is because the new iommufd_access_change_ioas() sets access-&gt;ioas to<br /> NULL during its process, so the lock might be gone in a concurrent racing<br /> context.<br /> <br /> Fix this by doing the same access-&gt;ioas sanity as iommufd_access_rw() and<br /> iommufd_access_pin_pages() functions do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix iopt_access_list_id overwrite bug<br /> <br /> Syzkaller reported the following WARN_ON:<br /> WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360<br /> <br /> Call Trace:<br /> iommufd_access_change_ioas+0x2fe/0x4e0<br /> iommufd_access_destroy_object+0x50/0xb0<br /> iommufd_object_remove+0x2a3/0x490<br /> iommufd_object_destroy_user<br /> iommufd_access_destroy+0x71/0xb0<br /> iommufd_test_staccess_release+0x89/0xd0<br /> __fput+0x272/0xb50<br /> __fput_sync+0x4b/0x60<br /> __do_sys_close<br /> __se_sys_close<br /> __x64_sys_close+0x8b/0x110<br /> do_syscall_x64<br /> <br /> The mismatch between the access pointer in the list and the passed-in<br /> pointer is resulting from an overwrite of access-&gt;iopt_access_list_id, in<br /> iopt_add_access(). Called from iommufd_access_change_ioas() when<br /> xa_alloc() succeeds but iopt_calculate_iova_alignment() fails.<br /> <br /> Add a new_id in iopt_add_access() and only update iopt_access_list_id when<br /> returning successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: mmci: stm32: fix DMA API overlapping mappings warning<br /> <br /> Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:<br /> <br /> DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568<br /> add_dma_entry+0x234/0x2f4<br /> Modules linked in:<br /> CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1<br /> Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)<br /> Workqueue: events_freezable mmc_rescan<br /> Call trace:<br /> add_dma_entry+0x234/0x2f4<br /> debug_dma_map_sg+0x198/0x350<br /> __dma_map_sg_attrs+0xa0/0x110<br /> dma_map_sg_attrs+0x10/0x2c<br /> sdmmc_idma_prep_data+0x80/0xc0<br /> mmci_prep_data+0x38/0x84<br /> mmci_start_data+0x108/0x2dc<br /> mmci_request+0xe4/0x190<br /> __mmc_start_request+0x68/0x140<br /> mmc_start_request+0x94/0xc0<br /> mmc_wait_for_req+0x70/0x100<br /> mmc_send_tuning+0x108/0x1ac<br /> sdmmc_execute_tuning+0x14c/0x210<br /> mmc_execute_tuning+0x48/0xec<br /> mmc_sd_init_uhs_card.part.0+0x208/0x464<br /> mmc_sd_init_card+0x318/0x89c<br /> mmc_attach_sd+0xe4/0x180<br /> mmc_rescan+0x244/0x320<br /> <br /> DMA API debug brings to light leaking dma-mappings as dma_map_sg and<br /> dma_unmap_sg are not correctly balanced.<br /> <br /> If an error occurs in mmci_cmd_irq function, only mmci_dma_error<br /> function is called and as this API is not managed on stm32 variant,<br /> dma_unmap_sg is never called in this error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: init irq after reg initialization<br /> <br /> Initialize the qDMA irqs after the registers are configured so that<br /> interrupts that may have been pending from a primary kernel don&amp;#39;t get<br /> processed by the irq handler before it is ready to and cause panic with<br /> the following trace:<br /> <br /> Call trace:<br /> fsl_qdma_queue_handler+0xf8/0x3e8<br /> __handle_irq_event_percpu+0x78/0x2b0<br /> handle_irq_event_percpu+0x1c/0x68<br /> handle_irq_event+0x44/0x78<br /> handle_fasteoi_irq+0xc8/0x178<br /> generic_handle_irq+0x24/0x38<br /> __handle_domain_irq+0x90/0x100<br /> gic_handle_irq+0x5c/0xb8<br /> el1_irq+0xb8/0x180<br /> _raw_spin_unlock_irqrestore+0x14/0x40<br /> __setup_irq+0x4bc/0x798<br /> request_threaded_irq+0xd8/0x190<br /> devm_request_threaded_irq+0x74/0xe8<br /> fsl_qdma_probe+0x4d4/0xca8<br /> platform_drv_probe+0x50/0xa0<br /> really_probe+0xe0/0x3f8<br /> driver_probe_device+0x64/0x130<br /> device_driver_attach+0x6c/0x78<br /> __driver_attach+0xbc/0x158<br /> bus_for_each_dev+0x5c/0x98<br /> driver_attach+0x20/0x28<br /> bus_add_driver+0x158/0x220<br /> driver_register+0x60/0x110<br /> __platform_driver_register+0x44/0x50<br /> fsl_qdma_driver_init+0x18/0x20<br /> do_one_initcall+0x48/0x258<br /> kernel_init_freeable+0x1a4/0x23c<br /> kernel_init+0x10/0xf8<br /> ret_from_fork+0x10/0x18