Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: fix PTM cycle trigger logic<br /> <br /> Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is<br /> triggered results in unreliable PTM operation. To fix this, clear the<br /> PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.<br /> <br /> The issue can be reproduced with the following:<br /> <br /> $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m<br /> <br /> Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to<br /> quickly reproduce the issue.<br /> <br /> PHC2SYS exits with:<br /> <br /> "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction<br /> fails<br /> <br /> This patch also fixes a hang in igc_probe() when loading the igc<br /> driver in the kdump kernel on systems supporting PTM.<br /> <br /> The igc driver running in the base kernel enables PTM trigger in<br /> igc_probe(). Therefore the driver is always in PTM trigger mode,<br /> except in brief periods when manually triggering a PTM cycle.<br /> <br /> When a crash occurs, the NIC is reset while PTM trigger is enabled.<br /> Due to a hardware problem, the NIC is subsequently in a bad busmaster<br /> state and doesn&amp;#39;t handle register reads/writes. When running<br /> igc_probe() in the kdump kernel, the first register access to a NIC<br /> register hangs driver probing and ultimately breaks kdump.<br /> <br /> With this patch, igc has PTM trigger disabled most of the time,<br /> and the trigger is only enabled for very brief (10 - 100 us) periods<br /> when manually triggering a PTM cycle. Chances that a crash occurs<br /> during a PTM trigger are not 0, but extremely reduced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS<br /> <br /> When testing a special config:<br /> <br /> CONFIG_NETFS_SUPPORTS=y<br /> CONFIG_PROC_FS=n<br /> <br /> The system crashes with something like:<br /> <br /> [ 3.766197] ------------[ cut here ]------------<br /> [ 3.766484] kernel BUG at mm/mempool.c:560!<br /> [ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W<br /> [ 3.767777] Tainted: [W]=WARN<br /> [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19<br /> [ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00<br /> [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286<br /> [ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000<br /> [ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff<br /> [ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828<br /> [ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0<br /> [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40<br /> [ 3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000<br /> [ 3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0<br /> [ 3.773884] PKRU: 55555554<br /> [ 3.774058] Call Trace:<br /> [ 3.774232] <br /> [ 3.774371] mempool_alloc_noprof+0x6a/0x190<br /> [ 3.774649] ? _printk+0x57/0x80<br /> [ 3.774862] netfs_alloc_request+0x85/0x2ce<br /> [ 3.775147] netfs_readahead+0x28/0x170<br /> [ 3.775395] read_pages+0x6c/0x350<br /> [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0<br /> [ 3.776247] filemap_get_pages+0x139/0x970<br /> [ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.776820] filemap_read+0xf9/0x580<br /> [ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.777674] ? find_held_lock+0x32/0x90<br /> [ 3.777929] ? netfs_start_io_read+0x19/0x70<br /> [ 3.778221] ? netfs_start_io_read+0x19/0x70<br /> [ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.778800] ? lock_acquired+0x1e6/0x450<br /> [ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 3.779379] netfs_buffered_read_iter+0x57/0x80<br /> [ 3.779670] __kernel_read+0x158/0x2c0<br /> [ 3.779927] bprm_execve+0x300/0x7a0<br /> [ 3.780185] kernel_execve+0x10c/0x140<br /> [ 3.780423] ? __pfx_kernel_init+0x10/0x10<br /> [ 3.780690] kernel_init+0xd5/0x150<br /> [ 3.780910] ret_from_fork+0x2d/0x50<br /> [ 3.781156] ? __pfx_kernel_init+0x10/0x10<br /> [ 3.781414] ret_from_fork_asm+0x1a/0x30<br /> [ 3.781677] <br /> [ 3.781823] Modules linked in:<br /> [ 3.782065] ---[ end trace 0000000000000000 ]---<br /> <br /> This is caused by the following error path in netfs_init():<br /> <br /> if (!proc_mkdir("fs/netfs", NULL))<br /> goto error_proc;<br /> <br /> Fix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only<br /> created with CONFIG_PROC_FS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Clear iommu-dma ops on cleanup<br /> <br /> If iommu_device_register() encounters an error, it can end up tearing<br /> down already-configured groups and default domains, however this<br /> currently still leaves devices hooked up to iommu-dma (and even<br /> historically the behaviour in this area was at best inconsistent across<br /> architectures/drivers...) Although in the case that an IOMMU is present<br /> whose driver has failed to probe, users cannot necessarily expect DMA to<br /> work anyway, it&amp;#39;s still arguable that we should do our best to put<br /> things back as if the IOMMU driver was never there at all, and certainly<br /> the potential for crashing in iommu-dma itself is undesirable. Make sure<br /> we clean up the dev-&gt;dma_iommu flag along with everything else.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue<br /> <br /> When the task management thread processes reply queues while the reset<br /> thread resets them, the task management thread accesses an invalid queue ID<br /> (0xFFFF), set by the reset thread, which points to unallocated memory,<br /> causing a crash.<br /> <br /> Add flag &amp;#39;io_admin_reset_sync&amp;#39; to synchronize access between the reset,<br /> I/O, and admin threads. Before a reset, the reset handler sets this flag to<br /> block I/O and admin processing threads. If any thread bypasses the initial<br /> check, the reset thread waits up to 10 seconds for processing to finish. If<br /> the wait exceeds 10 seconds, the controller is marked as unrecoverable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: pidff: Fix null pointer dereference in pidff_find_fields<br /> <br /> This function triggered a null pointer dereference if used to search for<br /> a report that isn&amp;#39;t implemented on the device. This happened both for<br /> optional and required reports alike.<br /> <br /> The same logic was applied to pidff_find_special_field and although<br /> pidff_init_fields should return an error earlier if one of the required<br /> reports is missing, future modifications could change this logic and<br /> resurface this possible null pointer dereference again.<br /> <br /> LKML bug report:<br /> https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: don&amp;#39;t allow datadir only<br /> <br /> In theory overlayfs could support upper layer directly referring to a data<br /> layer, but there&amp;#39;s no current use case for this.<br /> <br /> Originally, when data-only layers were introduced, this wasn&amp;#39;t allowed,<br /> only introduced by the "datadir+" feature, but without actually handling<br /> this case, resulting in an Oops.<br /> <br /> Fix by disallowing datadir without lowerdir.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: clean up FDB, MDB, VLAN entries on unbind<br /> <br /> As explained in many places such as commit b117e1e8a86d ("net: dsa:<br /> delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given<br /> the assumption that higher layers have balanced additions/deletions.<br /> As such, it only makes sense to be extremely vocal when those<br /> assumptions are violated and the driver unbinds with entries still<br /> present.<br /> <br /> But Ido Schimmel points out a very simple situation where that is wrong:<br /> https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/<br /> (also briefly discussed by me in the aforementioned commit).<br /> <br /> Basically, while the bridge bypass operations are not something that DSA<br /> explicitly documents, and for the majority of DSA drivers this API<br /> simply causes them to go to promiscuous mode, that isn&amp;#39;t the case for<br /> all drivers. Some have the necessary requirements for bridge bypass<br /> operations to do something useful - see dsa_switch_supports_uc_filtering().<br /> <br /> Although in tools/testing/selftests/net/forwarding/local_termination.sh,<br /> we made an effort to popularize better mechanisms to manage address<br /> filters on DSA interfaces from user space - namely macvlan for unicast,<br /> and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the<br /> fact is that &amp;#39;bridge fdb add ... self static local&amp;#39; also exists as<br /> kernel UAPI, and might be useful to someone, even if only for a quick<br /> hack.<br /> <br /> It seems counter-productive to block that path by implementing shim<br /> .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP<br /> in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from<br /> running, although we could do that.<br /> <br /> Accepting that cleanup is necessary seems to be the only option.<br /> Especially since we appear to be coming back at this from a different<br /> angle as well. Russell King is noticing that the WARN_ON() triggers even<br /> for VLANs:<br /> https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/<br /> <br /> What happens in the bug report above is that dsa_port_do_vlan_del() fails,<br /> then the VLAN entry lingers on, and then we warn on unbind and leak it.<br /> <br /> This is not a straight revert of the blamed commit, but we now add an<br /> informational print to the kernel log (to still have a way to see<br /> that bugs exist), and some extra comments gathered from past years&amp;#39;<br /> experience, to justify the logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported<br /> <br /> Russell King reports that on the ZII dev rev B, deleting a bridge VLAN<br /> from a user port fails with -ENOENT:<br /> https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/<br /> <br /> This comes from mv88e6xxx_port_vlan_leave() -&gt; mv88e6xxx_mst_put(),<br /> which tries to find an MST entry in &amp;chip-&gt;msts associated with the SID,<br /> but fails and returns -ENOENT as such.<br /> <br /> But we know that this chip does not support MST at all, so that is not<br /> surprising. The question is why does the guard in mv88e6xxx_mst_put()<br /> not exit early:<br /> <br /> if (!sid)<br /> return 0;<br /> <br /> And the answer seems to be simple: the sid comes from vlan.sid which<br /> supposedly was previously populated by mv88e6xxx_vtu_get().<br /> But some chip-&gt;info-&gt;ops-&gt;vtu_getnext() implementations do not populate<br /> vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,<br /> later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is<br /> just residual stack memory.<br /> <br /> Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge<br /> VLAN mapped to the default MSTI. For some chips, SID 0 is valid and<br /> installed by mv88e6xxx_stu_setup(). A chip which does not support the<br /> STU would implicitly only support mapping all VLANs to the default MSTI,<br /> so although SID 0 is not valid, it would be sufficient, if we were to<br /> zero-initialize the vlan structure, to fix the bug, due to the<br /> coincidence that a test for vlan.sid == 0 already exists and leads to<br /> the same (correct) behavior.<br /> <br /> Another option which would be sufficient would be to add a test for<br /> mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one<br /> which already exists in mv88e6xxx_mst_get(). But that placement means<br /> the caller will have to dereference vlan.sid, which means it will access<br /> uninitialized memory, which is not nice even if it ignores it later.<br /> <br /> So we end up making both modifications, in order to not rely just on the<br /> sid == 0 coincidence, but also to avoid having uninitialized structure<br /> fields which might get temporarily accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show()<br /> <br /> A warning is seen when running the latest kernel on a BlueField SOC:<br /> [251.512704] ------------[ cut here ]------------<br /> [251.512711] invalid sysfs_emit: buf:0000000003aa32ae<br /> [251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8<br /> <br /> The warning is triggered because the mlxbf-bootctl driver invokes<br /> "sysfs_emit()" with a buffer pointer that is not aligned to the<br /> start of the page. The driver should instead use "sysfs_emit_at()"<br /> to support non-zero offsets into the destination buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Silence oversized kvmalloc() warning<br /> <br /> syzkaller triggered an oversized kvmalloc() warning.<br /> Silence it by adding __GFP_NOWARN.<br /> <br /> syzkaller log:<br /> WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180<br /> CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__kvmalloc_node_noprof+0x175/0x180<br /> RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246<br /> RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b<br /> RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002<br /> RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000<br /> R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000<br /> FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ib_umem_odp_get+0x1f6/0x390<br /> mlx5_ib_reg_user_mr+0x1e8/0x450<br /> ib_uverbs_reg_mr+0x28b/0x440<br /> ib_uverbs_write+0x7d3/0xa30<br /> vfs_write+0x1ac/0x6c0<br /> ksys_write+0x134/0x170<br /> ? __sanitizer_cov_trace_pc+0x1c/0x50<br /> do_syscall_64+0x50/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/userptr: fix notifier vs folio deadlock<br /> <br /> User is reporting what smells like notifier vs folio deadlock, where<br /> migrate_pages_batch() on core kernel side is holding folio lock(s) and<br /> then interacting with the mappings of it, however those mappings are<br /> tied to some userptr, which means calling into the notifier callback and<br /> grabbing the notifier lock. With perfect timing it looks possible that<br /> the pages we pulled from the hmm fault can get sniped by<br /> migrate_pages_batch() at the same time that we are holding the notifier<br /> lock to mark the pages as accessed/dirty, but at this point we also want<br /> to grab the folio locks(s) to mark them as dirty, but if they are<br /> contended from notifier/migrate_pages_batch side then we deadlock since<br /> folio lock won&amp;#39;t be dropped until we drop the notifier lock.<br /> <br /> Fortunately the mark_page_accessed/dirty is not really needed in the<br /> first place it seems and should have already been done by hmm fault, so<br /> just remove it.<br /> <br /> (cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Use local fence in error path of xe_migrate_clear<br /> <br /> The intent of the error path in xe_migrate_clear is to wait on locally<br /> generated fence and then return. The code is waiting on m-&gt;fence which<br /> could be the local fence but this is only stable under the job mutex<br /> leading to a possible UAF. Fix code to wait on local fence.<br /> <br /> (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)