Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix out of bounds memory read error in symlink repair<br /> <br /> xfs/286 produced this report on my test fleet:<br /> <br /> ==================================================================<br /> BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110<br /> <br /> Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184):<br /> memcpy_orig+0x54/0x110<br /> xrep_symlink_salvage_inline+0xb3/0xf0 [xfs]<br /> xrep_symlink_salvage+0x100/0x110 [xfs]<br /> xrep_symlink+0x2e/0x80 [xfs]<br /> xrep_attempt+0x61/0x1f0 [xfs]<br /> xfs_scrub_metadata+0x34f/0x5c0 [xfs]<br /> xfs_ioc_scrubv_metadata+0x387/0x560 [xfs]<br /> xfs_file_ioctl+0xe23/0x10e0 [xfs]<br /> __x64_sys_ioctl+0x76/0xc0<br /> do_syscall_64+0x4e/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128<br /> <br /> allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago):<br /> xfs_init_local_fork+0x79/0xe0 [xfs]<br /> xfs_iformat_local+0xa4/0x170 [xfs]<br /> xfs_iformat_data_fork+0x148/0x180 [xfs]<br /> xfs_inode_from_disk+0x2cd/0x480 [xfs]<br /> xfs_iget+0x450/0xd60 [xfs]<br /> xfs_bulkstat_one_int+0x6b/0x510 [xfs]<br /> xfs_bulkstat_iwalk+0x1e/0x30 [xfs]<br /> xfs_iwalk_ag_recs+0xdf/0x150 [xfs]<br /> xfs_iwalk_run_callbacks+0xb9/0x190 [xfs]<br /> xfs_iwalk_ag+0x1dc/0x2f0 [xfs]<br /> xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs]<br /> xfs_iwalk+0xa4/0xd0 [xfs]<br /> xfs_bulkstat+0xfa/0x170 [xfs]<br /> xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs]<br /> xfs_file_ioctl+0xbf2/0x10e0 [xfs]<br /> __x64_sys_ioctl+0x76/0xc0<br /> do_syscall_64+0x4e/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014<br /> ==================================================================<br /> <br /> On further analysis, I realized that the second parameter to min() is<br /> not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data<br /> buffer. if_bytes can be smaller than the data fork size because:<br /> <br /> (a) the forkoff code tries to keep the data area as large as possible<br /> (b) for symbolic links, if_bytes is the ondisk file size + 1<br /> (c) forkoff is always a multiple of 8.<br /> <br /> Case in point: for a single-byte symlink target, forkoff will be<br /> 8 but the buffer will only be 2 bytes long.<br /> <br /> In other words, the logic here is wrong and we walk off the end of the<br /> incore buffer. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rv: Fully convert enabled_monitors to use list_head as iterator<br /> <br /> The callbacks in enabled_monitors_seq_ops are inconsistent. Some treat the<br /> iterator as struct rv_monitor *, while others treat the iterator as struct<br /> list_head *.<br /> <br /> This causes a wrong type cast and crashes the system as reported by Nathan.<br /> <br /> Convert everything to use struct list_head * as iterator. This also makes<br /> enabled_monitors consistent with available_monitors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: clear extent cache after moving/defragmenting extents<br /> <br /> The extent map cache can become stale when extents are moved or<br /> defragmented, causing subsequent operations to see outdated extent flags. <br /> This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().<br /> <br /> The problem occurs when:<br /> 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED<br /> 2. ioctl(FITRIM) triggers ocfs2_move_extents()<br /> 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)<br /> 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()<br /> which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)<br /> 5. The extent map cache is not invalidated after the move<br /> 6. Later write() operations read stale cached flags (0x2) but disk has<br /> updated flags (0x0), causing a mismatch<br /> 7. BUG_ON(!(rec-&gt;e_flags &amp; OCFS2_EXT_REFCOUNTED)) triggers<br /> <br /> Fix by clearing the extent map cache after each extent move/defrag<br /> operation in __ocfs2_move_extents_range(). This ensures subsequent<br /> operations read fresh extent data from disk.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: alienware-wmi-wmax: Fix NULL pointer dereference in sleep handlers<br /> <br /> Devices without the AWCC interface don&amp;#39;t initialize `awcc`. Add a check<br /> before dereferencing it in sleep handlers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()<br /> <br /> If fs_info-&gt;super_copy or fs_info-&gt;super_for_commit allocated failed in<br /> btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().<br /> Otherwise btrfs_check_leaked_roots() would access NULL pointer because<br /> fs_info-&gt;allocated_roots had not been initialised.<br /> <br /> syzkaller reported the following information:<br /> ------------[ cut here ]------------<br /> BUG: unable to handle page fault for address: fffffffffffffbb0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)<br /> RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]<br /> RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]<br /> RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]<br /> RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]<br /> RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230<br /> [...]<br /> Call Trace:<br /> <br /> btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280<br /> btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029<br /> btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097<br /> vfs_get_tree+0x98/0x320 fs/super.c:1759<br /> do_new_mount+0x357/0x660 fs/namespace.c:3899<br /> path_mount+0x716/0x19c0 fs/namespace.c:4226<br /> do_mount fs/namespace.c:4239 [inline]<br /> __do_sys_mount fs/namespace.c:4450 [inline]<br /> __se_sys_mount fs/namespace.c:4427 [inline]<br /> __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f032eaffa8d<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: zero unused hash fields<br /> <br /> When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to<br /> initialize the tunnel metadata but forget to zero unused rxhash<br /> fields. This may leak information to another side. Fixing this by<br /> zeroing the unused hash fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/notify: call exportfs_encode_fid with s_umount<br /> <br /> Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while<br /> the overlayfs is being unmounted, can lead to dereferencing NULL ptr.<br /> <br /> This issue was found by syzkaller.<br /> <br /> Race Condition Diagram:<br /> <br /> Thread 1 Thread 2<br /> -------- --------<br /> <br /> generic_shutdown_super()<br /> shrink_dcache_for_umount<br /> sb-&gt;s_root = NULL<br /> <br /> |<br /> | vfs_read()<br /> | inotify_fdinfo()<br /> | * inode get from mark *<br /> | show_mark_fhandle(m, inode)<br /> | exportfs_encode_fid(inode, ..)<br /> | ovl_encode_fh(inode, ..)<br /> | ovl_check_encode_origin(inode)<br /> | * deref i_sb-&gt;s_root *<br /> |<br /> |<br /> v<br /> fsnotify_sb_delete(sb)<br /> <br /> Which then leads to:<br /> <br /> [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)<br /> <br /> <br /> <br /> [ 32.143353] Call Trace:<br /> [ 32.143732] ovl_encode_fh+0xd5/0x170<br /> [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300<br /> [ 32.144425] show_mark_fhandle+0xbe/0x1f0<br /> [ 32.145805] inotify_fdinfo+0x226/0x2d0<br /> [ 32.146442] inotify_show_fdinfo+0x1c5/0x350<br /> [ 32.147168] seq_show+0x530/0x6f0<br /> [ 32.147449] seq_read_iter+0x503/0x12a0<br /> [ 32.148419] seq_read+0x31f/0x410<br /> [ 32.150714] vfs_read+0x1f0/0x9e0<br /> [ 32.152297] ksys_read+0x125/0x240<br /> <br /> IOW ovl_check_encode_origin derefs inode-&gt;i_sb-&gt;s_root, after it was set<br /> to NULL in the unmount path.<br /> <br /> Fix it by protecting calling exportfs_encode_fid() from<br /> show_mark_fhandle() with s_umount lock.<br /> <br /> This form of fix was suggested by Amir in [1].<br /> <br /> [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix IPsec cleanup over MPV device<br /> <br /> When we do mlx5e_detach_netdev() we eventually disable blocking events<br /> notifier, among those events are IPsec MPV events from IB to core.<br /> <br /> So before disabling those blocking events, make sure to also unregister<br /> the devcom device and mark all this device operations as complete,<br /> in order to prevent the other device from using invalid netdev<br /> during future devcom events which could cause the trace below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> PGD 146427067 P4D 146427067 PUD 146488067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40<br /> RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206<br /> RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00<br /> RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000<br /> R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600<br /> R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80<br /> FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x20/0x60<br /> ? page_fault_oops+0x150/0x3e0<br /> ? exc_page_fault+0x74/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core]<br /> mlx5_devcom_send_event+0x8c/0x170 [mlx5_core]<br /> blocking_event+0x17b/0x230 [mlx5_core]<br /> notifier_call_chain+0x35/0xa0<br /> blocking_notifier_call_chain+0x3d/0x60<br /> mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]<br /> mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core]<br /> mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib]<br /> mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib]<br /> ? idr_alloc_cyclic+0x50/0xb0<br /> ? __kmalloc_cache_noprof+0x167/0x340<br /> ? __kmalloc_noprof+0x1a7/0x430<br /> __mlx5_ib_add+0x34/0xd0 [mlx5_ib]<br /> mlx5r_probe+0xe9/0x310 [mlx5_ib]<br /> ? kernfs_add_one+0x107/0x150<br /> ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]<br /> auxiliary_bus_probe+0x3e/0x90<br /> really_probe+0xc5/0x3a0<br /> ? driver_probe_device+0x90/0x90<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> bus_for_each_drv+0x80/0xd0<br /> __device_attach+0xbc/0x1f0<br /> bus_probe_device+0x86/0xa0<br /> device_add+0x62d/0x830<br /> __auxiliary_device_add+0x3b/0xa0<br /> ? auxiliary_device_init+0x41/0x90<br /> add_adev+0xd1/0x150 [mlx5_core]<br /> mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core]<br /> esw_mode_change+0x6c/0xc0 [mlx5_core]<br /> mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core]<br /> devlink_nl_eswitch_set_doit+0x60/0xe0<br /> genl_family_rcv_msg_doit+0xd0/0x120<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_get_from_attrs_lock+0x170/0x170<br /> ? devlink_nl_eswitch_get_doit+0x290/0x290<br /> ? devlink_nl_pre_doit_port_optional+0x50/0x50<br /> ? genl_family_rcv_msg_dumpit+0xf0/0xf0<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1fc/0x2d0<br /> netlink_sendmsg+0x1e4/0x410<br /> __sock_sendmsg+0x38/0x60<br /> ? sockfd_lookup_light+0x12/0x60<br /> __sys_sendto+0x105/0x160<br /> ? __sys_recvmsg+0x4e/0x90<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f27bc91b13a<br /> Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: micrel: always set shared-&gt;phydev for LAN8814<br /> <br /> Currently, during the LAN8814 PTP probe shared-&gt;phydev is only set if PTP<br /> clock gets actually set, otherwise the function will return before setting<br /> it.<br /> <br /> This is an issue as shared-&gt;phydev is unconditionally being used when IRQ<br /> is being handled, especially in lan8814_gpio_process_cap and since it was<br /> not set it will cause a NULL pointer exception and crash the kernel.<br /> <br /> So, simply always set shared-&gt;phydev to avoid the NULL pointer exception.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix kernel panic on partial unmap of a GPU VA region<br /> <br /> This commit address a kernel panic issue that can happen if Userspace<br /> tries to partially unmap a GPU virtual region (aka drm_gpuva).<br /> The VM_BIND interface allows partial unmapping of a BO.<br /> <br /> Panthor driver pre-allocates memory for the new drm_gpuva structures<br /> that would be needed for the map/unmap operation, done using drm_gpuvm<br /> layer. It expected that only one new drm_gpuva would be needed on umap<br /> but a partial unmap can require 2 new drm_gpuva and that&amp;#39;s why it<br /> ended up doing a NULL pointer dereference causing a kernel panic.<br /> <br /> Following dump was seen when partial unmap was exercised.<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078<br /> Mem abort info:<br /> ESR = 0x0000000096000046<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000<br /> [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP<br /> <br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]<br /> sp : ffff800085d43970<br /> x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000<br /> x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000<br /> x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010<br /> x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c<br /> x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58<br /> x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c<br /> x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7<br /> x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001<br /> x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078<br /> Call trace:<br /> panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> op_remap_cb.isra.22+0x50/0x80<br /> __drm_gpuvm_sm_unmap+0x10c/0x1c8<br /> drm_gpuvm_sm_unmap+0x40/0x60<br /> panthor_vm_exec_op+0xb4/0x3d0 [panthor]<br /> panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]<br /> panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]<br /> drm_ioctl_kernel+0xbc/0x138<br /> drm_ioctl+0x240/0x500<br /> __arm64_sys_ioctl+0xb0/0xf8<br /> invoke_syscall+0x4c/0x110<br /> el0_svc_common.constprop.1+0x98/0xf8<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x40/0xf8<br /> el0t_64_sync_handler+0xa0/0xc8<br /> el0t_64_sync+0x174/0x178

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Account for failed debug initialization<br /> <br /> When the SCMI debug subsystem fails to initialize, the related debug root<br /> will be missing, and the underlying descriptor will be NULL.<br /> <br /> Handle this fault condition in the SCMI debug helpers that maintain<br /> metrics counters.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: dealloc commit test ctx always<br /> <br /> The damon_ctx for testing online DAMON parameters commit inputs is<br /> deallocated only when the test fails. This means memory is leaked for<br /> every successful online DAMON parameters commit. Fix the leak by always<br /> deallocating it.