| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
ACPICA: Avoid sequence overread in call to strncmp() stable inclusion from stable-6.6.95 commit 30e11a8cff732e50a5c2faef0f1f9498604aebff category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 64b9dfd0776e9c38d733094859a09f13282ce6f8 ] ACPICA commit 8b83a8d88dfec59ea147fad35fc6deea8859c58c ap_get_table_length() checks if tables are valid by calling ap_is_valid_header(). The latter then calls ACPI_VALIDATE_RSDP_SIG(Table->Signature). ap_is_valid_header() accepts struct acpi_table_header as an argument, so the signature size is always fixed to 4 bytes. The problem is when the string comparison is between ACPI-defined table signature and ACPI_SIG_RSDP. Common ACPI table header specifies the Signature field to be 4 bytes long[1], with the exception of the RSDP structure whose signature is 8 bytes long "RSD PTR " (including the trailing blank character)[2]. Calling strncmp(sig, rsdp_sig, 8) would then result in a sequence overread[3] as sig would be smaller (4 bytes) than the specified bound (8 bytes). As a workaround, pass the bound conditionally based on the size of the signature being passed. Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#system-description-table-header [1] Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp-structure [2] Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overread [3] Link: https://github.com/acpica/acpica/commit/8b83a8d8 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2248233.Mh6RI2rZIc@rjwysocki.net Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
ksmbd: add chann_lock to protect ksmbd_chann_list xarray stable inclusion from stable-6.6.100 commit 4f3a06cc57976cafa8c6f716646be6c79a99e485 category: bugfix issue: #209 CVE: CVE-2026-23226 Signed-off-by: Hun_Dun <18967138853@163.com> Co-Authored-By: Agent ------------------------------- ksmbd: add chann_lock to protect ksmbd_chann_list xarray ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del). Adds rw_semaphore chann_lock to struct ksmbd_session and protects all xa_load/xa_store/xa_erase accesses. Cc: stable@vger.kernel.org Reported-by: Igor Stepansky <igor.stepansky@orca.security> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Hun_Dun <18967138853@163.com> revert merge request: CVE修复: OpenHarmony-6.0-Release (76 个安全补丁) - 2026-04-20 c9410b6fe7a5a56939256a502589c01b244f2180 This revert merge request !353 | 4 个月前 | |
x86/hyperv: Fix hv tsc page based sched_clock for hibernation stable inclusion from stable-6.6.71 commit a6923798e471570ac1b24086be0a9679f51c3171 category: bugfix issue: #IBIAJE CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- commit bcc80dec91ee745b3d66f3e48f0ec2efdea97149 upstream. read_hv_sched_clock_tsc() assumes that the Hyper-V clock counter is bigger than the variable hv_sched_clock_offset, which is cached during early boot, but depending on the timing this assumption may be false when a hibernated VM starts again (the clock counter starts from 0 again) and is resuming back (Note: hv_init_tsc_clocksource() is not called during hibernation/resume); consequently, read_hv_sched_clock_tsc() may return a negative integer (which is interpreted as a huge positive integer since the return type is u64) and new kernel messages are prefixed with huge timestamps before read_hv_sched_clock_tsc() grows big enough (which typically takes several seconds). Fix the issue by saving the Hyper-V clock counter just before the suspend, and using it to correct the hv_sched_clock_offset in resume. This makes hv tsc page based sched_clock continuous and ensures that post resume, it starts from where it left off during suspend. Override x86_platform.save_sched_clock_state and x86_platform.restore_sched_clock_state routines to correct this as soon as possible. Note: if Invariant TSC is available, the issue doesn't happen because 1) we don't register read_hv_sched_clock_tsc() for sched clock: See commit e5313f1c5404 ("clocksource/drivers/hyper-v: Rework clocksource and sched clock setup"); 2) the common x86 code adjusts TSC similarly: see __restore_processor_state() -> tsc_verify_tsc_adjust(true) and x86_platform.restore_sched_clock_state(). Cc: stable@vger.kernel.org Fixes: 1349401ff1aa ("clocksource/drivers/hyper-v: Suspend/resume Hyper-V clocksource for hibernation") Co-developed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/20240917053917.76787-1-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20240917053917.76787-1-namjain@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg stable inclusion from stable-6.6.117 commit 1b34cbbf4f011a121ef7b2d7d6e6920a036d5285 category: bugfix issue: #321 CVE: CVE-2025-39964 Signed-off-by: liuyu82 <liuyu82@huawei.com> Co-Authored-By: Agent ------------------------------- crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing. Fixes: 8ff590903d5 ("crypto: algif_skcipher - User-space interface for skcipher operations") Reported-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg> Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: liuyu82 <liuyu82@huawei.com> Change-Id: Ic7db4f4d418a5fb0364a8e12295228784373b5bd | 4 个月前 | |
add kernel-6.6 pstore and blackbox Signed-off-by: wang_yonghai <wang_yonghai@runkaihong.com.cn> | 1 年前 | |
drm/framebuffer: Acquire internal references on GEM handles stable inclusion from stable-6.6.99 commit 2e2e9b3d708473040a08ab884f7dc2369752bb69 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280 upstream. Acquire GEM handles in drm_framebuffer_init() and release them in the corresponding drm_framebuffer_cleanup(). Ties the handle's lifetime to the framebuffer. Not all GEM buffer objects have GEM handles. If not set, no refcounting takes place. This is the case for some fbdev emulation. This is not a problem as these GEM objects do not use dma-bufs and drivers will not release them while fbdev emulation is running. Framebuffer flags keep a bit per color plane of which the framebuffer holds a GEM handle reference. As all drivers use drm_framebuffer_init(), they will now all hold dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers"). In the GEM framebuffer helpers, restore the original ref counting on buffer objects. As the helpers for handle refcounting are now no longer called from outside the DRM core, unexport the symbols. v3: - don't mix internal flags with mode flags (Christian) v2: - track framebuffer handle refs by flag - drop gma500 cleanup (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/ Tested-by: Bert Karwatzki <spasswolf@web.de> Tested-by: Mario Limonciello <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Anusha Srivatsa <asrivats@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
dt-bindings: clock: sunxi: Export PLL_VIDEO_2X and PLL_MIPI stable inclusion from stable-6.6.76 commit 11f5bdeff93e7a1da338c0531d51b196742b84ae category: bugfix issue: #IBLFX7 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- [ Upstream commit 9897831de614f1d8d5184547f0e7bf7665eed436 ] Export PLL_VIDEO_2X and PLL_MIPI, these will be used to explicitly select TCON0 clock parent in dts Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux") Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Frank Oltmanns <frank@oltmanns.dev> # on PinePhone Tested-by: Stuart Gathman <stuart@gathman.org> # on OG Pinebook Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://patch.msgid.link/20250104074035.1611136-2-anarsoul@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org> Stable-dep-of: 0f368cb7ef10 ("clk: sunxi-ng: a64: drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL_MIPI") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
integrity: PowerVM support for loading third party code signing keys On secure boot enabled PowerVM LPAR, third party code signing keys are needed during early boot to verify signed third party modules. These third party keys are stored in moduledb object in the Platform KeyStore (PKS). Load third party code signing keys onto .secondary_trusted_keys keyring. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> | 2 年前 | |
Merge tag 'mm-nonmm-stable-2023-08-28-22-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - An extensive rework of kexec and crash Kconfig from Eric DeVolder ("refactor Kconfig to consolidate KEXEC and CRASH options") - kernel.h slimming work from Andy Shevchenko ("kernel.h: Split out a couple of macros to args.h") - gdb feature work from Kuan-Ying Lee ("Add GDB memory helper commands") - vsprintf inclusion rationalization from Andy Shevchenko ("lib/vsprintf: Rework header inclusions") - Switch the handling of kdump from a udev scheme to in-kernel handling, by Eric DeVolder ("crash: Kernel handling of CPU and memory hot un/plug") - Many singleton patches to various parts of the tree * tag 'mm-nonmm-stable-2023-08-28-22-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (81 commits) document while_each_thread(), change first_tid() to use for_each_thread() drivers/char/mem.c: shrink character device's devlist[] array x86/crash: optimize CPU changes crash: change crash_prepare_elf64_headers() to for_each_possible_cpu() crash: hotplug support for kexec_load() x86/crash: add x86 crash hotplug support crash: memory and CPU hotplug sysfs attributes kexec: exclude elfcorehdr from the segment digest crash: add generic infrastructure for crash hotplug support crash: move a few code bits to setup support of crash hotplug kstrtox: consistently use _tolower() kill do_each_thread() nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse scripts/bloat-o-meter: count weak symbol sizes treewide: drop CONFIG_EMBEDDED lockdep: fix static memory detection even more lib/vsprintf: declare no_hash_pointers in sprintf.h lib/vsprintf: split out sprintf() and friends kernel/fork: stop playing lockless games for exe_file replacement adfs: delete unused "union adfs_dirtail" definition ... | 2 年前 | |
KVM: arm64: Fix host-programmed guest events in nVHE stable inclusion from stable-6.6.26 commit 9e2af26c29c6c6f1215d56c3246da148e54b2357 category: bugfix issue: #IAZXS9 CVE: NA Signed-off-by: zhangshuqi <zhangshuqi3@huawei.com> --------------------------------------- commit e89c928bedd77d181edc2df01cb6672184775140 upstream. Programming PMU events in the host that count during guest execution is a feature supported by perf, e.g. perf stat -e cpu_cycles:G ./lkvm run While this works for VHE, the guest/host event bitmaps are not carried through to the hypervisor in the nVHE configuration. Make kvm_pmu_update_vcpu_events() conditional on whether or not _hardware_ supports PMUv3 rather than if the vCPU as vPMU enabled. Cc: stable@vger.kernel.org Fixes: 84d751a019a9 ("KVM: arm64: Pass pmu events to hyp via vcpu") Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240305184840.636212-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zhangshuqi <zhangshuqi3@huawei.com> | 1 年前 | |
NFS: Fix a race when updating an existing write stable inclusion from stable-6.6.118 commit 76d2e3890fb169168c73f2e4f8375c7cc24a765e category: bugfix issue: CVE: CVE-2025-39697 Signed-off-by: Hun_Dun <18967138853@163.com> Co-Authored-By: Agent ------------------------------- NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request(). Reported-by: Jeff Layton <jlayton@kernel.org> Tested-by: Joe Quanaim <jdq@meta.com> Tested-by: Andrew Steffen <aksteffen@meta.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Fixes: bd37d6fce184 ("NFSv4: Convert nfs_lock_and_join_requests() to use nfs_page_find_head_request()") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Hun_Dun <18967138853@163.com> | 3 个月前 | |
powerpc/math-emu: Remove -w build flag and fix warnings As reported by Nathan, the module_init() macro was not taken into account because the header was missing. That means spe_mathemu_init() was never called. This should have been detected by gcc at build time, but due to '-w' flag it went undetected. Removing that flag leads to many warnings hence errors. Fix those warnings then remove the -w flag. Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/2663961738a46073713786d4efeb53100ca156e7.1662134272.git.christophe.leroy@csgroup.eu | 3 年前 | |
media: v4l: Memset argument to 0 before calling get_mbus_config pad op stable inclusion from stable-6.6.93 commit f8a9f45f75ab315553794e7cec8384546c33d281 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 91d6a99acfa5ce9f95ede775074b80f7193bd717 ] Memset the config argument to get_mbus_config V4L2 sub-device pad operation to zero before calling the operation. This ensures the callers don't need to bother with it nor the implementations need to set all fields that may not be relevant to them. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
memory: renesas-rpc-if: Remove Runtime PM wrappers Now the rpcif_{en,dis}able_rpm() wrappers just take a pointer to a device structure, there is no point in keeping them. Remove them, and update the callers to call Runtime PM directly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/d87aa5d7e4a39b18f7e2e0649fee0a45b45d371f.1669213027.git.geert+renesas@glider.be Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> | 3 年前 | |
cxl: fix typo in comment Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Acked-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220521111145.81697-82-Julia.Lawall@inria.fr | 3 年前 | |
Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' stable inclusion from stable-6.6.100 commit 2935e556850e9c94d7a00adf14d3cd7fe406ac03 category: bugfix issue: CVE: CVE-2025-38593 Signed-off-by: Hun_Dun <18967138853@163.com> Co-Authored-By: Agent ------------------------------- Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()' Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]--- Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Hun_Dun <18967138853@163.com> | 3 个月前 | |
ARM: pxa/sa1100: move I/O space to PCI_IOBASE PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual memory, using a per-bus io_offset that matches the base address of the ioremap mapping. In order for PXA to work in a multiplatform config, this needs to change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia soc_common support is shared with StrongARM1100, both have to change at the same time. The affected machines are: - Anything with a PCMCIA slot now uses pci_remap_iospace, which is made available to PCMCIA configurations as well, rather than just PCI. The first PCMCIA slot now starts at port number 0x10000. - The Zeus and Viper platforms have PC/104-style ISA buses, which have a static mapping for both I/O and memory space at 0xf1000000, which can no longer work. It does not appear to have any in-tree users, so moving it to port number 0 makes them behave like a traditional PC. - SA1100 does support ISA slots in theory, but all machines that originally enabled this appear to have been removed from the tree ages ago, and the I/O space is never mapped anywhere. - The Nanoengine machine has support for PCI slots, but looks like this never included I/O space, the resources only define the location for memory and config space. With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified, as the only remaining cases are the generic PCI_IOBASE and the custom inb()/outb() macros on RiscPC. S3C24xx still has a custom inb()/outb() in this here, but this is already removed in another branch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> | 4 年前 | |
mm, hwpoison: enable memory error handling on 1GB hugepage Now error handling code is prepared, so remove the blocking code and enable memory error handling on 1GB hugepage. Link: https://lkml.kernel.org/r/20220714042420.1847125-9-naoya.horiguchi@linux.dev Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Cc: David Hildenbrand <david@redhat.com> Cc: kernel test robot <lkp@intel.com> Cc: Liu Shixin <liushixin2@huawei.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> | 3 年前 | |
RDMA/uverbs: Propagate errors from rdma_lookup_get_uobject() stable inclusion from stable-6.6.93 commit 1bef1811651bc66479e211e0eee22067b549d790 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 81f8f7454ad9e0bf95efdec6542afdc9a6ab1e24 ] Currently, the IB uverbs API calls uobj_get_uobj_read(), which in turn uses the rdma_lookup_get_uobject() helper to retrieve user objects. In case of failure, uobj_get_uobj_read() returns NULL, overriding the error code from rdma_lookup_get_uobject(). The IB uverbs API then translates this NULL to -EINVAL, masking the actual error and complicating debugging. For example, applications calling ibv_modify_qp that fails with EBUSY when retrieving the QP uobject will see the overridden error code EINVAL instead, masking the actual error. Furthermore, based on rdma-core commit: "2a22f1ced5f3 ("Merge pull request #1568 from jakemoroni/master")" Kernel's IB uverbs return values are either ignored and passed on as is to application or overridden with other errnos in a few cases. Thus, to improve error reporting and debuggability, propagate the original error from rdma_lookup_get_uobject() instead of replacing it with EINVAL. Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Link: https://patch.msgid.link/64f9d3711b183984e939962c2f83383904f97dfb.1740577869.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
rv: Reset per-task monitors also for idle tasks stable inclusion from stable-6.6.78 commit 0796fa13788c860eca4164857f07d41932e39ba6 category: bugfix issue: #IC1IVT CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- commit 8259cb14a70680553d5e82d65d1302fe589e9b39 upstream. RV per-task monitors are implemented through a monitor structure available for each task_struct. This structure is reset every time the monitor is (re-)started, to avoid inconsistencies if the monitor was activated previously. To do so, we reset the monitor on all threads using the macro for_each_process_thread. However, this macro excludes the idle tasks on each CPU. Idle tasks could be considered tasks on their own right and it should be up to the model whether to ignore them or not. Reset monitors also on the idle tasks for each present CPU whenever we reset all per-task monitors. Cc: stable@vger.kernel.org Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: John Kacur <jkacur@redhat.com> Link: https://lore.kernel.org/20250115151547.605750-2-gmonaco@redhat.com Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros") Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
scsi: Remove scsi device no_start_on_resume flag stable inclusion from stable-6.6.57 commit 9e6075e112ee38bd2ac2309b925b4b74759054d2 category: bugfix issue: #IB7W7N CVE: NA Signed-off-by: zhangshuqi <zhangshuqi3@huawei.com> --------------------------------------- [ Upstream commit c4367ac83805a2322268c9736cd8ef9124063424 ] The scsi device flag no_start_on_resume is not set by any scsi low level driver. Remove it. This reverts the changes introduced by commit 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume"). Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.de> Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 7a6bbc2829d4 ("scsi: sd: Do not repeat the starting disk message") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zhangshuqi <zhangshuqi3@huawei.com> | 1 年前 | |
net: mscc: ocelot: treat 802.1ad tagged traffic as 802.1Q-untagged stable inclusion from stable-6.6.90 commit dc7ffe02adda25de57d3075fedabc4d1faabd726 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 36dd1141be70b5966906919714dc504a24c65ddf ] I was revisiting the topic of 802.1ad treatment in the Ocelot switch [0] and realized that not only is its basic VLAN classification pipeline improper for offloading vlan_protocol 802.1ad bridges, but also improper for offloading regular 802.1Q bridges already. Namely, 802.1ad-tagged traffic should be treated as VLAN-untagged by bridged ports, but this switch treats it as if it was 802.1Q-tagged with the same VID as in the 802.1ad header. This is markedly different to what the Linux bridge expects; see the "other_tpid()" function in tools/testing/selftests/net/forwarding/bridge_vlan_aware.sh. An idea came to me that the VCAP IS1 TCAM is more powerful than I'm giving it credit for, and that it actually overwrites the classified VID before the VLAN Table lookup takes place. In other words, it can be used even to save a packet from being dropped on ingress due to VLAN membership. Add a sophisticated TCAM rule hardcoded into the driver to force the switch to behave like a Linux bridge with vlan_filtering 1 vlan_protocol 802.1Q. Regarding the lifetime of the filter: eventually the bridge will disappear, and vlan_filtering on the port will be restored to 0 for standalone mode. Then the filter will be deleted. [0]: https://lore.kernel.org/netdev/20201009122947.nvhye4hvcha3tljh@skbuf/ Fixes: 7142529f1688 ("net: mscc: ocelot: add VLAN filtering") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Stable-dep-of: 5ec6d7d737a4 ("net: mscc: ocelot: delete PVID VLAN when readding it as non-PVID") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
ALSA: pcm: Fix race of buffer access at PCM OSS layer stable inclusion from stable-6.6.93 commit 74d90875f3d43f3eff0e9861c4701418795d3455 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- commit 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream. The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
scsi: target: iscsi: Remove the unused netif_timeout attribute This attribute has never been used, remove it. Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Link: https://lore.kernel.org/r/20230630155309.46061-1-mlombard@redhat.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> | 3 年前 | |
rxrpc: Fix recv-recv race of completed call stable inclusion from stable-6.6.100 commit 7692bde890061797f3dece0148d7859e85c55778 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc ] If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeffrey Altman <jaltman@auristor.com> cc: LePremierHomme <kwqcheii@proton.me> cc: Marc Dionne <marc.dionne@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250717074350.3767366-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
vsock/uapi: fix linux/vm_sockets.h userspace compilation errors stable inclusion from stable-6.6.96 commit 8f96a2ae16b5ede2746a2f4f5186b6981e1638fe category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 22bbc1dcd0d6785fb390c41f0dd5b5e218d23bdd ] If a userspace application just include <linux/vm_sockets.h> will fail to build with the following errors: /usr/include/linux/vm_sockets.h:182:39: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’ 182 | unsigned char svm_zero[sizeof(struct sockaddr) - | ^~~~~~ /usr/include/linux/vm_sockets.h:183:39: error: ‘sa_family_t’ undeclared here (not in a function) 183 | sizeof(sa_family_t) - | Include <sys/socket.h> for userspace (guarded by ifndef __KERNEL__) where struct sockaddr and sa_family_t are defined. We already do something similar in <linux/mptcp.h> and <linux/if.h>. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Daan De Meyer <daan.j.demeyer@gmail.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20250623100053.40979-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
scsi: ufs: core: Add OPP support for scaling clocks and regulators stable inclusion from stable-6.6.97 commit 847af89aa1635f42dac2f40ae042eb5d368b23d4 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 930bd77ebe3dc23b18aa49e55e6a515d5663d67a ] UFS core is only scaling the clocks during devfreq scaling and initialization. But for an optimum power saving, regulators should also be scaled along with the clocks. So let's use the OPP framework which supports scaling clocks, regulators, and performance state using OPP table defined in devicetree. For accomodating the OPP support, the existing APIs (ufshcd_scale_clks, ufshcd_is_devfreq_scaling_required and ufshcd_devfreq_scale) are modified to accept "freq" as an argument which in turn used by the OPP helpers. The OPP support is added along with the old freq-table based clock scaling so that the existing platforms work as expected. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231012172129.65172-3-manivannan.sadhasivam@linaro.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 2e083cd80229 ("scsi: ufs: core: Fix clk scaling to be conditional in reset and restore") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
vdso/bits.h: Add BIT_ULL() for the sake of consistency The minimization done in 3945ff37d2f4 ("linux/bits.h: Extract common header for vDSO") was required to isolate the VDSO build from the larger kernel header impact. The split added some inconsistency since BIT() and BIT_ULL() are now defined in the different files which confuses unprepared reader. Move BIT_ULL() to vdso/bits.h. No functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20221128141003.77929-1-andriy.shevchenko@linux.intel.com | 3 年前 | |
fbdev: stifb: Make the STI next font pointer a 32-bit signed offset commit 8a32aa17c1cd48df1ddaa78e45abcb8c7a2220d6 upstream. The pointer to the next STI font is actually a signed 32-bit offset. With this change the 64-bit kernel will correctly subract the (signed 32-bit) offset instead of adding a (unsigned 32-bit) offset. It has no effect on 32-bit kernels. This fixes the stifb driver with a 64-bit kernel on qemu. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
xen/mcelog: Add __nonstring annotations for unterminated strings stable inclusion from stable-6.6.88 commit af71db7de0679e91f2e9e82868df8e7a2fe695b2 category: bugfix issue: #IC6IH3 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- [ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ] When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Cc: xen-devel@lists.xenproject.org Signed-off-by: Kees Cook <kees@kernel.org> Acked-by: Juergen Gross <jgross@suse.com> Message-ID: <20250310222234.work.473-kees@kernel.org> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 |