Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix merge preference rule failure condition<br /> <br /> syzbot reported a lock held when returning to userspace[1]. This is<br /> because if argc is less than 0 and the function returns directly, the held<br /> inode lock is not released.<br /> <br /> Fix this by store the error in ret and jump to done to clean up instead of<br /> returning directly.<br /> <br /> [dh: Modified Lizhi Xu&amp;#39;s original patch to make it honour the error code<br /> from afs_split_string()]<br /> <br /> [1]<br /> WARNING: lock held when returning to user space!<br /> 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted<br /> ------------------------------------------------<br /> syz-executor133/5823 is leaving the kernel with locks still held!<br /> 1 lock held by syz-executor133/5823:<br /> #0: ffff888071cffc00 (&amp;sb-&gt;s_type-&gt;i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline]<br /> #0: ffff888071cffc00 (&amp;sb-&gt;s_type-&gt;i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double free of TCP_Server_Info::hostname<br /> <br /> When shutting down the server in cifs_put_tcp_session(), cifsd thread<br /> might be reconnecting to multiple DFS targets before it realizes it<br /> should exit the loop, so @server-&gt;hostname can&amp;#39;t be freed as long as<br /> cifsd thread isn&amp;#39;t done. Otherwise the following can happen:<br /> <br /> RIP: 0010:__slab_free+0x223/0x3c0<br /> Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89<br /> 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <br /> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80<br /> RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246<br /> RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068<br /> RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400<br /> RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500<br /> R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068<br /> FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)<br /> 000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? __reconnect_target_unlocked+0x3e/0x160 [cifs]<br /> ? __die_body.cold+0x8/0xd<br /> ? die+0x2b/0x50<br /> ? do_trap+0xce/0x120<br /> ? __slab_free+0x223/0x3c0<br /> ? do_error_trap+0x65/0x80<br /> ? __slab_free+0x223/0x3c0<br /> ? exc_invalid_op+0x4e/0x70<br /> ? __slab_free+0x223/0x3c0<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __slab_free+0x223/0x3c0<br /> ? extract_hostname+0x5c/0xa0 [cifs]<br /> ? extract_hostname+0x5c/0xa0 [cifs]<br /> ? __kmalloc+0x4b/0x140<br /> __reconnect_target_unlocked+0x3e/0x160 [cifs]<br /> reconnect_dfs_server+0x145/0x430 [cifs]<br /> cifs_handle_standard+0x1ad/0x1d0 [cifs]<br /> cifs_demultiplex_thread+0x592/0x730 [cifs]<br /> ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]<br /> kthread+0xdd/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x29/0x50<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel<br /> <br /> Attempt to enable IPsec packet offload in tunnel mode in debug kernel<br /> generates the following kernel panic, which is happening due to two<br /> issues:<br /> 1. In SA add section, the should be _bh() variant when marking SA mode.<br /> 2. There is not needed flush_workqueue in SA delete routine. It is not<br /> needed as at this stage as it is removed from SADB and the running work<br /> will be canceled later in SA free.<br /> <br /> =====================================================<br /> WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected<br /> 6.12.0+ #4 Not tainted<br /> -----------------------------------------------------<br /> charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:<br /> ffff88810f365020 (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]<br /> <br /> and this task is already holding:<br /> ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> which would create a new lock dependency:<br /> (&amp;x-&gt;lock){+.-.}-{3:3} -&gt; (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> but this new dependency connects a SOFTIRQ-irq-safe lock:<br /> (&amp;x-&gt;lock){+.-.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-safe at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> hrtimer_run_softirq+0x146/0x2e0<br /> handle_softirqs+0x266/0x860<br /> irq_exit_rcu+0x115/0x1a0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> default_idle+0x13/0x20<br /> default_idle_call+0x67/0xa0<br /> do_idle+0x2da/0x320<br /> cpu_startup_entry+0x50/0x60<br /> start_secondary+0x213/0x2a0<br /> common_startup_64+0x129/0x138<br /> <br /> to a SOFTIRQ-irq-unsafe lock:<br /> (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-unsafe at:<br /> ...<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock+0x2c/0x40<br /> xa_set_mark+0x70/0x110<br /> mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]<br /> xfrm_dev_state_add+0x3bb/0xd70<br /> xfrm_add_sa+0x2451/0x4a90<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> other info that might help us debug this:<br /> <br /> Possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> local_irq_disable();<br /> lock(&amp;x-&gt;lock);<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> <br /> lock(&amp;x-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 2 locks held by charon/1337:<br /> #0: ffffffff87f8f858 (&amp;net-&gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90<br /> #1: ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> <br /> the dependencies between SOFTIRQ-irq-safe lock and the holding lock:<br /> -&gt; (&amp;x-&gt;lock){+.-.}-{3:3} ops: 29 {<br /> HARDIRQ-ON-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_alloc_spi+0xc0/0xe60<br /> xfrm_alloc_userspi+0x5f6/0xbc0<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> IN-SOFTIRQ-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pfcp: Destroy device along with udp socket&amp;#39;s netns dismantle.<br /> <br /> pfcp_newlink() links the device to a list in dev_net(dev) instead<br /> of net, where a udp tunnel socket is created.<br /> <br /> Even when net is removed, the device stays alive on dev_net(dev).<br /> Then, removing net triggers the splat below. [0]<br /> <br /> In this example, pfcp0 is created in ns2, but the udp socket is<br /> created in ns1.<br /> <br /> ip netns add ns1<br /> ip netns add ns2<br /> ip -n ns1 link add netns ns2 name pfcp0 type pfcp<br /> ip netns del ns1<br /> <br /> Let&amp;#39;s link the device to the socket&amp;#39;s netns instead.<br /> <br /> Now, pfcp_net_exit() needs another netdev iteration to remove<br /> all pfcp devices in the netns.<br /> <br /> pfcp_dev_list is not used under RCU, so the list API is converted<br /> to the non-RCU variant.<br /> <br /> pfcp_net_exit() can be converted to .exit_batch_rtnl() in net-next.<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@00000000128b34dc has 1/1 users at<br /> sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)<br /> inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1558)<br /> udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)<br /> pfcp_create_sock (drivers/net/pfcp.c:168)<br /> pfcp_newlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197)<br /> rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2542)<br /> netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1891)<br /> ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)<br /> ___sys_sendmsg (net/socket.c:2639)<br /> __sys_sendmsg (net/socket.c:2669)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> WARNING: CPU: 1 PID: 11 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89<br /> RSP: 0018:ff11000007f3fb60 EFLAGS: 00010286<br /> RAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c<br /> RBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230<br /> R13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:748)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:285)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)<br /> ? kfree (mm/slub.c:4613 mm/slub.c:4761)<br /> net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)<br /> cleanup_net (net/cor<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix potential UAF of zram table<br /> <br /> If zram_meta_alloc failed early, it frees allocated zram-&gt;table without<br /> setting it NULL. Which will potentially cause zram_meta_free to access<br /> the table if user reset an failed and uninitialized device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Clear port select structure when fail to create<br /> <br /> Clear the port select structure on error so no stale values left after<br /> definers are destroyed. That&amp;#39;s because the mlx5_lag_destroy_definers()<br /> always try to destroy all lag definers in the tt_map, so in the flow<br /> below lag definers get double-destroyed and cause kernel crash:<br /> <br /> mlx5_lag_port_sel_create()<br /> mlx5_lag_create_definers()<br /> mlx5_lag_create_definer()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: handle page_pool_dev_alloc_pages error<br /> <br /> The fec_enet_update_cbd function calls page_pool_dev_alloc_pages but did<br /> not handle the case when it returned NULL. There was a WARN_ON(!new_page)<br /> but it would still proceed to use the NULL pointer and then crash.<br /> <br /> This case does seem somewhat rare but when the system is under memory<br /> pressure it can happen. One case where I can duplicate this with some<br /> frequency is when writing over a smbd share to a SATA HDD attached to an<br /> imx6q.<br /> <br /> Setting /proc/sys/vm/min_free_kbytes to higher values also seems to solve<br /> the problem for my test case. But it still seems wrong that the fec driver<br /> ignores the memory allocation error and can crash.<br /> <br /> This commit handles the allocation error by dropping the current packet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: discard packets if the transport changes<br /> <br /> If the socket has been de-assigned or assigned to another transport,<br /> we must discard any packets received because they are not expected<br /> and would cause issues when we access vsk-&gt;transport.<br /> <br /> A possible scenario is described by Hyunwoo Kim in the attached link,<br /> where after a first connect() interrupted by a signal, and a second<br /> connect() failed, we can find `vsk-&gt;transport` at NULL, leading to a<br /> NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Destroy device along with udp socket&amp;#39;s netns dismantle.<br /> <br /> gtp_newlink() links the device to a list in dev_net(dev) instead of<br /> src_net, where a udp tunnel socket is created.<br /> <br /> Even when src_net is removed, the device stays alive on dev_net(dev).<br /> Then, removing src_net triggers the splat below. [0]<br /> <br /> In this example, gtp0 is created in ns2, and the udp socket is created<br /> in ns1.<br /> <br /> ip netns add ns1<br /> ip netns add ns2<br /> ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn<br /> ip netns del ns1<br /> <br /> Let&amp;#39;s link the device to the socket&amp;#39;s netns instead.<br /> <br /> Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove<br /> all gtp devices in the netns.<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at<br /> sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)<br /> inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1558)<br /> udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)<br /> gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)<br /> gtp_create_sockets (drivers/net/gtp.c:1447)<br /> gtp_newlink (drivers/net/gtp.c:1507)<br /> rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2542)<br /> netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1891)<br /> ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)<br /> ___sys_sendmsg (net/socket.c:2639)<br /> __sys_sendmsg (net/socket.c:2669)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> <br /> WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89<br /> RSP: 0018:ff11000009a07b60 EFLAGS: 00010286<br /> RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c<br /> RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae<br /> R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0<br /> R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:748)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:285)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)<br /> ? kfree (mm/slub.c:4613 mm/slub.c:4761)<br /> net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)<br /> cleanup_net (net/core/net_namespace.c:664 (discriminator 3))<br /> process_one_work (kernel/workqueue.c:3229)<br /> worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: avoid truncating 64-bit offset to 32 bits<br /> <br /> On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a<br /> 64-bit value to 32 bits, leading to a possible infinite loop when writing<br /> to an xfs filesystem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: avoid avoid truncating 64-bit offset to 32 bits<br /> <br /> on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a<br /> 32-bit position due to folio_next_index() returning an unsigned long.<br /> This could lead to an infinite loop when writing to an xfs filesystem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8mp-blk-ctrl: add missing loop break condition<br /> <br /> Currently imx8mp_blk_ctrl_remove() will continue the for loop<br /> until an out-of-bounds exception occurs.<br /> <br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : dev_pm_domain_detach+0x8/0x48<br /> lr : imx8mp_blk_ctrl_shutdown+0x58/0x90<br /> sp : ffffffc084f8bbf0<br /> x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000<br /> x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028<br /> x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0<br /> x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff<br /> x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72<br /> x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000<br /> x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8<br /> x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077<br /> x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000<br /> Call trace:<br /> dev_pm_domain_detach+0x8/0x48<br /> platform_shutdown+0x2c/0x48<br /> device_shutdown+0x158/0x268<br /> kernel_restart_prepare+0x40/0x58<br /> kernel_kexec+0x58/0xe8<br /> __do_sys_reboot+0x198/0x258<br /> __arm64_sys_reboot+0x2c/0x40<br /> invoke_syscall+0x5c/0x138<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0xc8<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x190/0x198<br /> Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f