| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
firmware_loader: Fix possible resource leak in fw_log_firmware_info() stable inclusion from stable-6.6.64 commit 789a72498d32f88d24371c10985aceb46397056c category: bugfix issue: #IBE7K0 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- [ Upstream commit 369a9c046c2fdfe037f05b43b84c386bdbccc103 ] The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails. Fixes: 02fe26f25325 ("firmware_loader: Add debug message with checksum for FW file") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Russ Weight <russ.weight@linux.dev> Link: https://lore.kernel.org/r/20241016110335.3677924-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
pmdomain: governor: Consider CPU latency tolerance from pm_domain_cpu_gov stable inclusion from stable-6.6.100 commit 600f55da8d909f93638c65de3df666969463f806 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- commit 500ba33284416255b9a5b50ace24470b6fe77ea5 upstream. pm_domain_cpu_gov is selecting a cluster idle state but does not consider latency tolerance of child CPUs. This results in deeper cluster idle state whose latency does not meet latency tolerance requirement. Select deeper idle state only if global and device latency tolerance of all child CPUs meet. Test results on SM8750 with 300 usec PM-QoS on CPU0 which is less than domain idle state entry (2150) + exit (1983) usec latency mentioned in devicetree, demonstrate the issue. # echo 300 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us Before: (Usage is incrementing) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 29817 537 8 270 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 30348 542 8 271 0 After: (Usage is not incrementing due to latency tolerance) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Fixes: e94999688e3a ("PM / Domains: Add genpd governor for CPUs") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250709-pmdomain_qos-v2-1-976b12257899@oss.qualcomm.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
regmap: maple: free entry on mas_store_gfp() failure [ Upstream commit f3f380ce6b3d5c9805c7e0b3d5bc28d9ec41e2e8 ] regcache_maple_write() allocates a new block ('entry') to merge adjacent ranges and then stores it with mas_store_gfp(). When mas_store_gfp() fails, the new 'entry' remains allocated and is never freed, leaking memory. Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper'). Link: https://patch.msgid.link/20260105031820.260119-1-kaushlendra.kumar@intel.com Signed-off-by: llj123 <luojie119@h-partners.com> | 3 个月前 | |
drivers: base: test: Add missing MODULE_* macros to root device tests Commit 06188bc80ccb ("drivers: base: Add basic devm tests for root devices") introduced a new set of tests for root devices that could be compiled as a module, but didn't have the usual module macros. Make sure they're there. Fixes: 06188bc80ccb ("drivers: base: Add basic devm tests for root devices") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20230816073019.1446155-2-mripard@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
driver core: Add CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT Add a build time equivalent of fw_devlink.sync_state=timeout so that board specific kernels could enable it and not have to deal with setting or cluttering the kernel commandline. Cc: Doug Anderson <dianders@chromium.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230317205134.964098-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN Adjust to reality and remove another layer of pointless Kconfig indirection. CONFIG_GENERIC_MSI_IRQ is good enough to serve all purposes. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221111122014.524842979@linutronix.de | 3 年前 | |
arm64: irq: set the correct node for VMAP stack [ Upstream commit 75b5e0bf90bffaca4b1f19114065dc59f5cc161f ] In current code, init_irq_stacks() will call cpu_to_node(). The cpu_to_node() depends on percpu "numa_node" which is initialized in: arch_call_rest_init() --> rest_init() -- kernel_init() --> kernel_init_freeable() --> smp_prepare_cpus() But init_irq_stacks() is called in init_IRQ() which is before arch_call_rest_init(). So in init_irq_stacks(), the cpu_to_node() does not work, it always return 0. In NUMA, it makes the node 1 cpu accesses the IRQ stack which is in the node 0. This patch fixes it by: 1.) export the early_cpu_to_node(), and use it in the init_irq_stacks(). 2.) change init_irq_stacks() to __init function. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Link: https://lore.kernel.org/r/20231124031513.81548-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 2 年前 | |
arch_topology: Remove early cacheinfo error message if -ENOENT fetch_cache_info() tries to get the number of cache leaves/levels for each CPU in order to pre-allocate memory for cacheinfo struct. Allocating this memory later triggers a: 'BUG: sleeping function called from invalid context' in PREEMPT_RT kernels. If there is no cache related information available in DT or ACPI, fetch_cache_info() fails and an error message is printed: 'Early cacheinfo failed, ret = ...' Not having cache information should be a valid configuration. Remove the error message if fetch_cache_info() fails with -ENOENT. Suggested-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> | 3 年前 | |
driver core: attribute_container: fix W=1 warnings Fix the following make W=1 kernel build warnings: drivers/base/attribute_container.c:304: warning: Function parameter or member 'fn' not described in 'attribute_container_device_trigger_safe' drivers/base/attribute_container.c:304: warning: Function parameter or member 'undo' not described in 'attribute_container_device_trigger_safe' drivers/base/attribute_container.c:357: warning: Function parameter or member 'fn' not described in 'attribute_container_device_trigger' Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210512072233.3817056-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 5 年前 | |
driver core: make struct bus_type.uevent() take a const * The uevent() callback in struct bus_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: fix potential NULL pointer dereference in dev_uevent() stable inclusion from stable-6.6.89 commit abe56be73eb10a677d16066f65ff9d30251f5eee category: bugfix issue: #IC6IH3 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- commit 18daa52418e7e4629ed1703b64777294209d2622 upstream. If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it. Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20250311052417.1846985-3-dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
fix: correct multiple backporting compilation errors - CVE-2026-23343/43009: Remove is_atomic_load_insn() reference (not in 6.6) - CVE-2026-23383: Fix bpf_jit_binary_alloc() argument list in bpf_jit_comp.c - CVE-2026-31527: Add driver_override prerequisite commit (device_has_driver_override) - CVE-2026-43053: Add xfs_attr3_node_entry_remove and xfs_attr3_leaf_init helpers Change-Id: Ia384a4939e15d5f2f7cdae38468bd27b31a6a4b5 Signed-off-by: 姜小林 <jiangxiaolin11@huawei.com> | 3 个月前 | |
cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU stable inclusion from stable-6.6.66 commit 23b5908b11b77ff8d7b8f7b8f11cbab2e1f4bfc2 category: bugfix issue: #IBE7K0 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- commit b3fce429a1e030b50c1c91351d69b8667eef627b upstream. Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU") adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed. If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier. Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation. Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet. While here, remove an unnecessary indentation in allocate_cache_info(). [ bp: Massage. ] Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Radu Rendec <rrendec@redhat.com> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Reviewed-by: Andreas Herrmann <aherrmann@suse.de> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Cc: stable@vger.kernel.org # 6.3+ Link: https://lore.kernel.org/r/20241128002247.26726-2-ricardo.neri-calderon@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
driver core: class: Fix wild pointer dereferences in API class_dev_iter_next() stable inclusion from stable-6.6.76 commit f4b9bc823b0cfdebfed479c0e87d6939c7562e87 category: bugfix issue: #IBLFX7 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- [ Upstream commit e128f82f7006991c99a58114f70ef61e937b1ac1 ] There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage: // All members of @iter are wild pointers. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...); // Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... }; // Also dereference these wild pointers here. class_dev_iter_exit(&iter); Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next(). Fixes: 7b884b7f24b4 ("driver core: class.c: convert to only use class_to_subsys") Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-1-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
drivers: base: component: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230202141621.2296458-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: Remove redundant license text Now that the SPDX tag is in all driver core files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 8 年前 | |
fix: correct multiple backporting compilation errors - CVE-2026-23343/43009: Remove is_atomic_load_insn() reference (not in 6.6) - CVE-2026-23383: Fix bpf_jit_binary_alloc() argument list in bpf_jit_comp.c - CVE-2026-31527: Add driver_override prerequisite commit (device_has_driver_override) - CVE-2026-43053: Add xfs_attr3_node_entry_remove and xfs_attr3_leaf_init helpers Change-Id: Ia384a4939e15d5f2f7cdae38468bd27b31a6a4b5 Signed-off-by: 姜小林 <jiangxiaolin11@huawei.com> | 3 个月前 | |
x86/bugs: Add a Transient Scheduler Attacks mitigation stable inclusion from stable-6.6.97 commit 90293047df18caf7ed0fe566d89af0720f2dc98a category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- Commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream. Add the required features detection glue to bugs.c et all in order to support the TSA mitigation. Co-developed-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
fix: correct multiple backporting compilation errors - CVE-2026-23343/43009: Remove is_atomic_load_insn() reference (not in 6.6) - CVE-2026-23383: Fix bpf_jit_binary_alloc() argument list in bpf_jit_comp.c - CVE-2026-31527: Add driver_override prerequisite commit (device_has_driver_override) - CVE-2026-43053: Add xfs_attr3_node_entry_remove and xfs_attr3_leaf_init helpers Change-Id: Ia384a4939e15d5f2f7cdae38468bd27b31a6a4b5 Signed-off-by: 姜小林 <jiangxiaolin11@huawei.com> | 3 个月前 | |
devcoredump: Send uevent once devcd is ready commit af54d778a03853801d681c98c0c2a6c316ef9ca7 upstream. dev_coredumpm() creates a devcoredump device and adds it to the core kernel framework which eventually end up sending uevent to the user space and later creates a symbolic link to the failed device. An application running in userspace may be interested in this symbolic link to get the name of the failed device. In a issue scenario, once uevent sent to the user space it start reading '/sys/class/devcoredump/devcdX/failing_device' to get the actual name of the device which might not been created and it is in its path of creation. To fix this, suppress sending uevent till the failing device symbolic link gets created and send uevent once symbolic link is created successfully. Fixes: 833c95456a70 ("device coredump: add new device coredump class") Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1700232572-25823-1-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
drivers: base: devres: Allow to release group on device release stable inclusion from stable-6.6.88 commit 61d1a8296eeb151192cba42f29532849ac536373 category: bugfix issue: #IC6IH3 CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- [ Upstream commit 8e1ddfada4530939a8cb64ee9251aef780474274 ] When releasing a device, if the release action causes a group to be released, a warning is emitted because it can't find the group. This happens because devres_release_all() moves the entire list to a todo list and also move the group markers. Considering r* normal resource nodes and g1 a group resource node: g1 -----------. v v r1 -> r2 -> g1[0] -> r3-> g[1] -> r4 After devres_release_all(), dev->devres_head becomes empty and the todo list it iterates on becomes: g1 v r1 -> r2 -> r3-> r4 -> g1[0] When a call to component_del() is made and takes down the aggregate device, a warning like this happen: RIP: 0010:devres_release_group+0x362/0x530 ... Call Trace: <TASK> component_unbind+0x156/0x380 component_unbind_all+0x1d0/0x270 mei_component_master_unbind+0x28/0x80 [mei_hdcp] take_down_aggregate_device+0xc1/0x160 component_del+0x1c6/0x3e0 intel_hdcp_component_fini+0xf1/0x170 [xe] xe_display_fini+0x1e/0x40 [xe] Because the devres group corresponding to the hdcp component cannot be found. Just ignore this corner case: if the dev->devres_head is empty and the caller is trying to remove a group, it's likely in the process of device cleanup so just ignore it instead of warning. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250222001051.3012936-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
driver core: clean up the logic to determine which /sys/dev/ directory to use When a dev_t is set in a struct device, an symlink in /sys/dev/ is created for it either under /sys/dev/block/ or /sys/dev/char/ depending on the device type. The logic to determine this would trigger off of the class of the object, and the kobj_type set in that location. But it turns out that this deep nesting isn't needed at all, as it's either a choice of block or "everything else" which is a char device. So make the logic a lot more simple and obvious, and remove the incorrect comments in the code that tried to document something that was not happening at all (it is impossible to set class->dev_kobj to NULL as the class core prevented that from happening. This removes the only place that class->dev_kobj was being used, so after this, it can be removed entirely. Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20230331093318.82288-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: create bus_is_registered() A local function to the driver core to determine if a bus really is registered with the kernel or not. To be used only by the driver core code, as part of the driver registration path as it's not really "safe" because the bus could be unregistered instantly after being called. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20230208111330.439504-17-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: Remove redundant license text Now that the SPDX tag is in all driver core files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 8 年前 | |
driver core: Remove redundant license text Now that the SPDX tag is in all driver core files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 8 年前 | |
init: Initialize noop_backing_dev_info early noop_backing_dev_info is used by superblocks of various pseudofilesystems such as kdevtmpfs. After commit 10e14073107d ("writeback: Fix inode->i_io_list not be protected by inode->i_lock error") this broke because __mark_inode_dirty() started to access more fields from noop_backing_dev_info and this led to crashes inside locked_inode_to_wb_and_lock_list() called from __mark_inode_dirty(). Fix the problem by initializing noop_backing_dev_info before the filesystems get mounted. Fixes: 10e14073107d ("writeback: Fix inode->i_io_list not be protected by inode->i_lock error") Reported-and-tested-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reported-and-tested-by: Alexandru Elisei <alexandru.elisei@arm.com> Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jan Kara <jack@suse.cz> | 4 年前 | |
isa: Remove unnecessary checks The isa_dev->dev.platform_data is initialized with incoming parameter isa_driver. After it isa_dev->dev.platform_data is checked for NULL, but incoming parameter isa_driver is not NULL since it is dereferenced many times before this check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Vladislav Efanov <VEfanov@ispras.ru> Acked-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/20230517125025.434005-1-VEfanov@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver: base: Prefer unsigned int to bare use of unsigned Fix checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by: Jinchao Wang <wjc@cdjrlc.com> Link: https://lore.kernel.org/r/20210628171907.63646-2-wjc@cdjrlc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 5 年前 | |
mm/memory_hotplug: add missing mem_hotplug_lock commit 001002e73712cdf6b8d9a103648cda3040ad7647 upstream. From Documentation/core-api/memory-hotplug.rst: When adding/removing/onlining/offlining memory or adding/removing heterogeneous/device memory, we should always hold the mem_hotplug_lock in write mode to serialise memory hotplug (e.g. access to global/zone variables). mhp_(de)init_memmap_on_memory() functions can change zone stats and struct page content, but they are currently called w/o the mem_hotplug_lock. When memory block is being offlined and when kmemleak goes through each populated zone, the following theoretical race conditions could occur: CPU 0: | CPU 1: memory_offline() | -> offline_pages() | -> mem_hotplug_begin() | ... | -> mem_hotplug_done() | | kmemleak_scan() | -> get_online_mems() | ... -> mhp_deinit_memmap_on_memory() | [not protected by mem_hotplug_begin/done()]| Marks memory section as offline, | Retrieves zone_start_pfn poisons vmemmap struct pages and updates | and struct page members. the zone related data | | ... | -> put_online_mems() Fix this by ensuring mem_hotplug_lock is taken before performing mhp_init_memmap_on_memory(). Also ensure that mhp_deinit_memmap_on_memory() holds the lock. online/offline_pages() are currently only called from memory_block_online/offline(), so it is safe to move the locking there. Link: https://lkml.kernel.org/r/20231120145354.308999-2-sumanthk@linux.ibm.com Fixes: a08a2ae34613 ("mm,memory_hotplug: allocate memmap from the added memory range") Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: kernel test robot <lkp@intel.com> Cc: <stable@vger.kernel.org> [5.15+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
drivers: base: handle module_kobject creation stable inclusion from stable-6.6.90 commit 8f2451ebaf5b8adffdbdf2ee42e4adf94d213aec category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit f95bbfe18512c5c018720468959edac056a17196 ] module_add_driver() relies on module_kset list for /sys/module/<built-in-module>/drivers directory creation. Since, commit 96a1a2412acba ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time") drivers which are initialized from subsys_initcall() or any other higher precedence initcall couldn't find the related kobject entry in the module_kset list because module_kset is not fully populated by the time module_add_driver() refers it. As a consequence, module_add_driver() returns early without calling make_driver_name(). Therefore, /sys/module/<built-in-module>/drivers is never created. Fix this issue by letting module_add_driver() handle module_kobject creation itself. Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time") Cc: stable@vger.kernel.org # requires all other patches from the series Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250227184930.34163-5-shyamsaini@linux.microsoft.com Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
base/node.c: initialize the accessor list before registering [ Upstream commit 48b5928e18dc27e05cab3dc4c78cd8a15baaf1e5 ] The current code registers the node as available in the node array before initializing the accessor list. This makes it so that anything which might access the accessor list as a result of allocations will cause an undefined memory access. In one example, an extension to access hmat data during interleave caused this undefined access as a result of a bulk allocation that occurs during node initialization but before the accessor list is initialized. Initialize the accessor list before making the node generally available to the global system. Fixes: 08d9dbe72b1f ("node: Link memory nodes to their compute nodes") Signed-off-by: Gregory Price <gregory.price@memverge.com> Link: https://lore.kernel.org/r/20231030044239.971756-1-gregory.price@memverge.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> | 2 年前 | |
driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it. Fixes: bc443c31def5 ("driver core: location: Check for allocations failure") Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/1669102648-11517-1-git-send-email-guohanjun@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: physical_location.h remove extern from function prototypes The kernel coding style does not require 'extern' in function prototypes in .h files, so remove them from drivers/base/physical_location.h as they are not needed. Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20230324122711.2664537-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
driver core: Remove redundant license text Now that the SPDX tag is in all driver core files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 8 年前 | |
genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced Miquel reported a warning in the MSI core which is triggered when interrupts are freed via platform_msi_device_domain_free(). This code got reworked to use core functions for freeing the MSI descriptors, but nothing took care to clear the msi_desc->irq entry, which then triggers the warning in msi_free_msi_desc() which uses desc->irq to validate that the descriptor has been torn down. The same issue exists in msi_domain_populate_irqs(). Up to the point that msi_free_msi_descs() grew a warning for this case, this went un-noticed. Provide the counterpart of msi_domain_populate_irqs() and invoke it in platform_msi_device_domain_free() before freeing the interrupts and MSI descriptors and also in the error path of msi_domain_populate_irqs(). Fixes: 2f2940d16823 ("genirq/msi: Remove filter from msi_free_descs_free_range()") Reported-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87mt4wkwnv.ffs@tglx | 3 年前 | |
driver core: platform: use generic driver_override infrastructure mainline inclusion from mainline-6.6.100 commit 2b38efc05bf7a8568ec74bfffea0f5cfa62bc01d category: bugfix issue: #617 CVE: CVE-2026-31527 Signed-off-by: 姜小林 <jiangxiaolin11@huawei.com> Co-Authored-By: Agent ------------------------------- driver core: platform: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han <hanguidong02@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260303115720.48783-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Change-Id: I117b6089c6768e06e0496df571f64ff397d01f74 Signed-off-by: 姜小林 <jiangxiaolin11@huawei.com> | 3 个月前 | |
drivers: fwnode: fix fwnode_irq_get[_byname]() The fwnode_irq_get() and the fwnode_irq_get_byname() return 0 upon device-tree IRQ mapping failure. This is contradicting the fwnode_irq_get_byname() function documentation and can potentially be a source of errors like: int probe(...) { ... irq = fwnode_irq_get_byname(); if (irq <= 0) return irq; ... } Here we do correctly check the return value from fwnode_irq_get_byname() but the driver probe will now return success. (There was already one such user in-tree). Change the fwnode_irq_get_byname() to work as documented and make also the fwnode_irq_get() follow same common convention returning a negative errno upon failure. Fixes: ca0acb511c21 ("device property: Add fwnode_irq_get_byname") Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-ID: <3e64fe592dc99e27ef9a0b247fc49fa26b6b8a58.1685340157.git.mazziesaccount@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
base: soc: populate machine name in soc_device_register if empty Several SoC drivers use the same of-based mechanism to populate the machine name. Therefore move this to the core and try to populate the machine name in soc_device_register if it's not set yet. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/6dbdf458-9f46-613e-de58-b4a56a6cdd9f@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
software node: Correct a OOB check in software_node_get_reference_args() stable inclusion from stable-6.6.95 commit f9397cf7bfb680799fb8c7f717c8f756384c3280 category: bugfix issue: #ICCW0G CVE: NA Signed-off-by: Li Nan <linan122@huawei.com> --------------------------------------- [ Upstream commit 31e4e12e0e9609850cefd4b2e1adf782f56337d6 ] software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250414-fix_swnode-v2-1-9c9e6ae11eab@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Li Nan <linan122@huawei.com> | 1 年前 | |
syscore: Use pm_pr_dbg() for syscore_{suspend,resume}() The debug messages about what syscore suspend/resume hooks are called are only present if you have initcall debugging enabled. Let's move these messages to pm_pr_dbg() so that the syscore PM messages are included along with all the other PM debugging info that can be seen during suspend/resume debugging. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200806214633.204472-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 5 年前 | |
topology: Keep the cpumask unchanged when printing cpumap stable inclusion from stable-6.6.72 commit b02cf1d27e460ab2b3e1c8c9ce472d562cad2e8d category: bugfix issue: #IBIAJE CVE: NA Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> --------------------------------------- commit cbd399f78e23ad4492c174fc5e6b3676dba74a52 upstream. During fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The call trace shows that kvasprintf() reported this warning during the printing of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent. If the core_cpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify core_cpumask while printing. To fix this issue, cache the cpumask into a temporary variable before calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged during the printing process. Fixes: bb9ec13d156e ("topology: use bin_attribute to break the size limitation of cpumap ABI") Cc: stable <stable@kernel.org> Signed-off-by: Li Huafei <lihuafei1@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20241114110141.94725-1-lihuafei1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zyf1116 <zhouyongfei3@huawei.com> | 1 年前 | |
devres: Enable trace events In some cases the printf() mechanism is too heavy and can't be used. For example, when debugging a race condition involving devres API. When CONFIG_DEBUG_DEVRES is enabled I can't reproduce an issue, and otherwise it's quite visible with a useful information being collected. Enable trace events for devres part of the driver core. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210517122946.53161-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 5 年前 | |
devres: Enable trace events In some cases the printf() mechanism is too heavy and can't be used. For example, when debugging a race condition involving devres API. When CONFIG_DEBUG_DEVRES is enabled I can't reproduce an issue, and otherwise it's quite visible with a useful information being collected. Enable trace events for devres part of the driver core. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210517122946.53161-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 5 年前 | |
drivers: base: transport_class: fix resource leak when transport_add_device() fails The normal call sequence of using transport class is: Add path: transport_setup_device() transport_setup_classdev() // call sas_host_setup() here transport_add_device() // if fails, need call transport_destroy_device() transport_configure_device() Remove path: transport_remove_device() transport_remove_classdev // call sas_host_remove() here transport_destroy_device() If transport_add_device() fails, need call transport_destroy_device() to free memory, but in this case, ->remove() is not called, and the resources allocated in ->setup() are leaked. So fix these leaks by calling ->remove() in transport_add_class_device() if it returns error. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221115031638.3816551-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 3 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 8 年前 | ||
| 3 个月前 | ||
| 1 年前 | ||
| 3 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 8 年前 | ||
| 8 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 8 年前 | ||
| 3 年前 | ||
| 3 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 |