May 2025 - Linux-stable-mirror

[PATCH AUTOSEL 6.12 01/26] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

3 months, 1 week

1
25
0 0

[PATCH AUTOSEL 6.14 01/28] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

3 months, 1 week

1
27
0 0

[PATCH AUTOSEL 6.15 01/30] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

3 months, 1 week

1
29
0 0

[PATCH v2] mmc: sdhci-omap: Add error handling for sdhci_runtime_suspend_host()

by Wentao Liang

The sdhci_omap_runtime_suspend() calls sdhci_runtime_suspend_host() but does not handle the return value. A proper implementation can be found in sdhci_am654_runtime_suspend(). Add error handling for sdhci_runtime_suspend_host(). Return the error code if the suspend fails. Fixes: 51189eb9ddc8 ("mmc: sdhci-omap: Fix a lockdep warning for PM runtime init") Cc: stable(a)vger.kernel.org # 5.19 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- v2: Fix code error. drivers/mmc/host/sdhci-omap.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c index 54d795205fb4..f09f78cf244d 100644 --- a/drivers/mmc/host/sdhci-omap.c +++ b/drivers/mmc/host/sdhci-omap.c @@ -1438,12 +1438,16 @@ static int __maybe_unused sdhci_omap_runtime_suspend(struct device *dev) struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host); + int ret; if (host->tuning_mode != SDHCI_TUNING_MODE_3) mmc_retune_needed(host->mmc); - if (omap_host->con != -EINVAL) - sdhci_runtime_suspend_host(host); + if (omap_host->con != -EINVAL) { + ret = sdhci_runtime_suspend_host(host); + if (ret) + return ret; + } sdhci_omap_context_save(omap_host); -- 2.42.0.windows.2

3 months, 1 week

2
1
0 0

[PATCH] mmc: sdhci-sprd: Add error handling for sdhci_runtime_suspend_host()

by Wentao Liang

The dhci_sprd_runtime_suspend() calls sdhci_runtime_suspend_host() but does not handle the return value. A proper implementation can be found in sdhci_am654_runtime_suspend(). Add error handling for sdhci_runtime_suspend_host(). Return the error code if the suspend fails. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable(a)vger.kernel.org # v4.20 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/mmc/host/sdhci-sprd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c index db5e253b0f79..dd41427e973a 100644 --- a/drivers/mmc/host/sdhci-sprd.c +++ b/drivers/mmc/host/sdhci-sprd.c @@ -922,9 +922,12 @@ static int sdhci_sprd_runtime_suspend(struct device *dev) { struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host); + int ret; mmc_hsq_suspend(host->mmc); - sdhci_runtime_suspend_host(host); + ret = sdhci_runtime_suspend_host(host); + if (ret) + return ret; clk_disable_unprepare(sprd_host->clk_sdio); clk_disable_unprepare(sprd_host->clk_enable); -- 2.42.0.windows.2

3 months, 1 week

3
2
0 0

Unlock CWIEME Berlin 2025 Attendee List!

by Garnet Conwell

Hi, We’re thrilled to give you exclusive access to the CWIEME Berlin 2025 Visitor Contact List! This database includes 8,678 verified visitor contacts and 550 exhibitor contacts, each with detailed Each contact contains: Contact name, Job Title, Business Name, Physical Address, Phone Numbers, Official Email address and many more. Limited-Time Offer: Get 20% OFF – Valid only until May 31st. Interested? Simply reply with “Send me pricing” to receive more details. Kind regards, Garnet Conwell Sr. Marketing Manager P.S. Don’t want to receive these updates? Just reply with “Unfollow.”

3 months, 1 week

1
0
0 0

[PATCH 5.15 00/59] 5.15.184-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.184 release. There are 59 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 22 May 2025 12:57:37 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.184-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.15.184-rc1 Alexander Lobakin <alexandr.lobakin(a)intel.com> ice: arfs: fix use-after-free when freeing @rx_cpu_rmap Florian Westphal <fw(a)strlen.de> netfilter: nf_tables: do not defer rule destruction via call_rcu Pablo Neira Ayuso <pablo(a)netfilter.org> netfilter: nf_tables: wait for rcu grace period on net_device removal Florian Westphal <fw(a)strlen.de> netfilter: nf_tables: pass nft_chain to destroy function, not nft_ctx Josef Bacik <josef(a)toxicpanda.com> btrfs: do not clean up repair bio if submit fails Filipe Manana <fdmanana(a)suse.com> btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Eric Dumazet <edumazet(a)google.com> sctp: add mutual exclusion in proc_sctp_do_udp_port() Feng Tang <feng.tang(a)linux.alibaba.com> selftests/mm: compaction_test: support platform with huge mount of memory GONG Ruiqi <gongruiqi1(a)huawei.com> usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control() Dan Carpenter <dan.carpenter(a)linaro.org> usb: typec: fix potential array underflow in ucsi_ccg_sync_control() RD Babiera <rdbabiera(a)google.com> usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group Andrei Kuchynski <akuchynski(a)chromium.org> usb: typec: ucsi: displayport: Fix deadlock Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> clocksource/i8253: Use raw_spinlock_irqsave() in clockevent_i8253_disable() Fengnan Chang <changfengnan(a)bytedance.com> block: fix direct io NOWAIT flag not work Shuai Xue <xueshuai(a)linux.alibaba.com> dmaengine: idxd: fix memory leak in error handling path of idxd_setup_groups Shuai Xue <xueshuai(a)linux.alibaba.com> dmaengine: idxd: fix memory leak in error handling path of idxd_setup_engines Yemike Abhilash Chandra <y-abhilashchandra(a)ti.com> dmaengine: ti: k3-udma: Use cap_mask directly from dma_device structure instead of a local copy Ronald Wahl <ronald.wahl(a)legrand.com> dmaengine: ti: k3-udma: Add missing locking Fedor Pchelkin <pchelkin(a)ispras.ru> wifi: mt76: disable napi on driver removal Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> phy: renesas: rcar-gen3-usb2: Set timing registers only once Ma Ke <make24(a)iscas.ac.cn> phy: Fix error handling in tegra_xusb_port_init Steven Rostedt <rostedt(a)goodmis.org> tracing: samples: Initialize trace_array_printk() with the correct function pengdonglin <pengdonglin(a)xiaomi.com> ftrace: Fix preemption accounting for stacktrace filter command pengdonglin <pengdonglin(a)xiaomi.com> ftrace: Fix preemption accounting for stacktrace trigger command Nicolas Chauvet <kwizart(a)gmail.com> ALSA: usb-audio: Add sample rate quirk for Microdia JP001 USB Camera Christian Heusel <christian(a)heusel.eu> ALSA: usb-audio: Add sample rate quirk for Audioengine D1 Wentao Liang <vulab(a)iscas.ac.cn> ALSA: es1968: Add error handling for snd_pcm_hw_constraint_pow2() Jeremy Linton <jeremy.linton(a)arm.com> ACPI: PPTT: Fix processor subtable walk Filipe Manana <fdmanana(a)suse.com> btrfs: fix discard worker infinite loop after disabling discard Nathan Lynch <nathan.lynch(a)amd.com> dmaengine: Revert "dmaengine: dmatest: Fix dmatest waiting less when interrupted" Peter Zijlstra <peterz(a)infradead.org> x86/its: FineIBT-paranoid vs ITS Eric Biggers <ebiggers(a)google.com> x86/its: Fix build errors when CONFIG_MODULES=n Peter Zijlstra <peterz(a)infradead.org> x86/its: Use dynamic thunks for indirect branches Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Align RETs in BHB clear sequence to avoid thunking Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add "vmexit" option to skip mitigation on some CPUs Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Enable Indirect Target Selection mitigation Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add support for ITS-safe return thunk Josh Poimboeuf <jpoimboe(a)kernel.org> x86/alternatives: Remove faulty optimization Borislav Petkov (AMD) <bp(a)alien8.de> x86/alternative: Optimize returns patching Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add support for ITS-safe indirect thunk Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Enumerate Indirect Target Selection (ITS) bug Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Documentation: x86/bugs/its: Add ITS documentation Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Remove the extra #ifdef around CALL_NOSPEC Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Add a conditional CS prefix to CALL_NOSPEC Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Simplify and make CALL_NOSPEC consistent Peter Zijlstra <peterz(a)infradead.org> x86,nospec: Simplify {JMP,CALL}_NOSPEC Trond Myklebust <trond.myklebust(a)hammerspace.com> NFSv4/pnfs: Reset the layout state after a layoutreturn Abdun Nihaal <abdun.nihaal(a)gmail.com> qlcnic: fix memory leak in qlcnic_sriov_channel_cfg_cmd() Geert Uytterhoeven <geert+renesas(a)glider.be> ALSA: sh: SND_AICA should depend on SH_DMA_API Vladimir Oltean <vladimir.oltean(a)nxp.com> net: dsa: sja1105: discard incoming frames in BR_STATE_LISTENING Mathieu Othacehe <othacehe(a)gnu.org> net: cadence: macb: Fix a possible deadlock in macb_halt_tx. Cong Wang <xiyou.wangcong(a)gmail.com> net_sched: Flush gso_skb list too during ->change() Geert Uytterhoeven <geert+renesas(a)glider.be> spi: loopback-test: Do not split 1024-byte hexdumps Li Lingfeng <lilingfeng3(a)huawei.com> nfs: handle failure of nfs_get_lock_context in unlock path Zhu Yanjun <yanjun.zhu(a)linux.dev> RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug David Lechner <dlechner(a)baylibre.com> iio: chemical: sps30: use aligned_s64 for timestamp Jonathan Cameron <Jonathan.Cameron(a)huawei.com> iio: adc: ad7768-1: Fix insufficient alignment of timestamp. Masami Hiramatsu (Google) <mhiramat(a)kernel.org> tracing: probes: Fix a possible race in trace_probe_log APIs Hans de Goede <hdegoede(a)redhat.com> platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection ------------- Diffstat: Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 156 +++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 15 ++ Makefile | 4 +- arch/x86/Kconfig | 11 + arch/x86/entry/entry_64.S | 20 +- arch/x86/include/asm/alternative.h | 32 +++ arch/x86/include/asm/cpufeatures.h | 3 + arch/x86/include/asm/msr-index.h | 8 + arch/x86/include/asm/nospec-branch.h | 57 +++-- arch/x86/kernel/alternative.c | 243 ++++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 139 +++++++++++- arch/x86/kernel/cpu/common.c | 63 +++++- arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/module.c | 7 + arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 10 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 ++++ arch/x86/net/bpf_jit_comp.c | 8 +- block/fops.c | 5 +- drivers/acpi/pptt.c | 11 +- drivers/base/cpu.c | 8 + drivers/clocksource/i8253.c | 6 +- drivers/dma/dmatest.c | 6 +- drivers/dma/idxd/init.c | 8 + drivers/dma/ti/k3-udma.c | 10 +- drivers/iio/adc/ad7768-1.c | 2 +- drivers/iio/chemical/sps30.c | 2 +- drivers/infiniband/sw/rxe/rxe_cq.c | 5 +- drivers/net/dsa/sja1105/sja1105_main.c | 6 +- drivers/net/ethernet/cadence/macb_main.c | 19 +- drivers/net/ethernet/intel/ice/ice_arfs.c | 9 +- drivers/net/ethernet/intel/ice/ice_lib.c | 5 +- drivers/net/ethernet/intel/ice/ice_main.c | 20 +- .../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 7 +- drivers/net/wireless/mediatek/mt76/dma.c | 1 + drivers/phy/renesas/phy-rcar-gen3-usb2.c | 7 +- drivers/phy/tegra/xusb.c | 8 +- drivers/platform/x86/asus-wmi.c | 3 +- drivers/spi/spi-loopback-test.c | 2 +- drivers/usb/typec/altmodes/displayport.c | 18 +- drivers/usb/typec/ucsi/displayport.c | 19 +- drivers/usb/typec/ucsi/ucsi.c | 34 +++ drivers/usb/typec/ucsi/ucsi.h | 3 + drivers/usb/typec/ucsi/ucsi_ccg.c | 5 + fs/btrfs/discard.c | 17 +- fs/btrfs/extent-tree.c | 25 ++- fs/btrfs/extent_io.c | 15 +- fs/nfs/nfs4proc.c | 9 +- fs/nfs/pnfs.c | 9 + include/linux/cpu.h | 2 + include/linux/module.h | 5 + include/net/netfilter/nf_tables.h | 2 +- include/net/sch_generic.h | 15 ++ kernel/trace/trace_dynevent.c | 16 +- kernel/trace/trace_dynevent.h | 1 + kernel/trace/trace_events_trigger.c | 2 +- kernel/trace/trace_functions.c | 6 +- kernel/trace/trace_kprobe.c | 2 +- kernel/trace/trace_probe.c | 9 + kernel/trace/trace_uprobe.c | 2 +- net/netfilter/nf_tables_api.c | 54 +++-- net/netfilter/nft_immediate.c | 2 +- net/sched/sch_codel.c | 2 +- net/sched/sch_fq.c | 2 +- net/sched/sch_fq_codel.c | 2 +- net/sched/sch_fq_pie.c | 2 +- net/sched/sch_hhf.c | 2 +- net/sched/sch_pie.c | 2 +- net/sctp/sysctl.c | 4 + samples/ftrace/sample-trace-array.c | 2 +- sound/pci/es1968.c | 6 +- sound/sh/Kconfig | 2 +- sound/usb/quirks.c | 4 + tools/testing/selftests/vm/compaction_test.c | 19 +- 77 files changed, 1112 insertions(+), 184 deletions(-)

3 months, 1 week

13
77
0 0

Are there any internal kernel ABI/API guarantees in -stable releases?

by Chris Friesen

Hi everyone, Looking at https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html there are a number of criteria for patches to -stable releases. However, there is no mention of preserving the stability of internal kernel ABIs and/or APIs. Do successive patch releases of -stable kernels provide any guarantees that they will not change ABIs and/or APIs, remove functionality, change behaviour, etc.? For example, would a -stable commit be allowed to make a change that would break an out-of-tree (but open-source) device driver if that's the only way to fix a bug? I know that during the development of new major/minor versions developers are free to break ABIs and APIs at will as long as they fix up all the in-tree code. Does that still hold true for -stable commits or do things get more restrictive? Thanks, Chris

3 months, 1 week

2
1
0 0

+ mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix the inaccurate memory statistics issue for users has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Baolin Wang <baolin.wang(a)linux.alibaba.com> Subject: mm: fix the inaccurate memory statistics issue for users Date: Sat, 24 May 2025 09:59:53 +0800 On some large machines with a high number of CPUs running a 64K pagesize kernel, we found that the 'RES' field is always 0 displayed by the top command for some processes, which will cause a lot of confusion for users. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 875525 root 20 0 12480 0 0 R 0.3 0.0 0:00.08 top 1 root 20 0 172800 0 0 S 0.0 0.0 0:04.52 systemd The main reason is that the batch size of the percpu counter is quite large on these machines, caching a significant percpu value, since converting mm's rss stats into percpu_counter by commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter"). Intuitively, the batch number should be optimized, but on some paths, performance may take precedence over statistical accuracy. Therefore, introducing a new interface to add the percpu statistical count and display it to users, which can remove the confusion. In addition, this change is not expected to be on a performance-critical path, so the modification should be acceptable. Link: https://lkml.kernel.org/r/4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.17480518… Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Tested-by Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Tested-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Acked-by: SeongJae Park <sj(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 14 +++++++------- include/linux/mm.h | 5 +++++ 2 files changed, 12 insertions(+), 7 deletions(-) --- a/fs/proc/task_mmu.c~mm-fix-the-inaccurate-memory-statistics-issue-for-users +++ a/fs/proc/task_mmu.c @@ -36,9 +36,9 @@ void task_mem(struct seq_file *m, struct unsigned long text, lib, swap, anon, file, shmem; unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss; - anon = get_mm_counter(mm, MM_ANONPAGES); - file = get_mm_counter(mm, MM_FILEPAGES); - shmem = get_mm_counter(mm, MM_SHMEMPAGES); + anon = get_mm_counter_sum(mm, MM_ANONPAGES); + file = get_mm_counter_sum(mm, MM_FILEPAGES); + shmem = get_mm_counter_sum(mm, MM_SHMEMPAGES); /* * Note: to minimize their overhead, mm maintains hiwater_vm and @@ -59,7 +59,7 @@ void task_mem(struct seq_file *m, struct text = min(text, mm->exec_vm << PAGE_SHIFT); lib = (mm->exec_vm << PAGE_SHIFT) - text; - swap = get_mm_counter(mm, MM_SWAPENTS); + swap = get_mm_counter_sum(mm, MM_SWAPENTS); SEQ_PUT_DEC("VmPeak:\t", hiwater_vm); SEQ_PUT_DEC(" kB\nVmSize:\t", total_vm); SEQ_PUT_DEC(" kB\nVmLck:\t", mm->locked_vm); @@ -92,12 +92,12 @@ unsigned long task_statm(struct mm_struc unsigned long *shared, unsigned long *text, unsigned long *data, unsigned long *resident) { - *shared = get_mm_counter(mm, MM_FILEPAGES) + - get_mm_counter(mm, MM_SHMEMPAGES); + *shared = get_mm_counter_sum(mm, MM_FILEPAGES) + + get_mm_counter_sum(mm, MM_SHMEMPAGES); *text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> PAGE_SHIFT; *data = mm->data_vm + mm->stack_vm; - *resident = *shared + get_mm_counter(mm, MM_ANONPAGES); + *resident = *shared + get_mm_counter_sum(mm, MM_ANONPAGES); return mm->total_vm; } --- a/include/linux/mm.h~mm-fix-the-inaccurate-memory-statistics-issue-for-users +++ a/include/linux/mm.h @@ -2708,6 +2708,11 @@ static inline unsigned long get_mm_count return percpu_counter_read_positive(&mm->rss_stat[member]); } +static inline unsigned long get_mm_counter_sum(struct mm_struct *mm, int member) +{ + return percpu_counter_sum_positive(&mm->rss_stat[member]); +} + void mm_trace_rss_stat(struct mm_struct *mm, int member); static inline void add_mm_counter(struct mm_struct *mm, int member, long value) _ Patches currently in -mm which might be from baolin.wang(a)linux.alibaba.com are mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch

3 months, 1 week

1
0
0 0

Re: [PATCH v2 1/1] netfilter: load nf_log_syslog on enabling nf_conntrack_log_invalid

by Lance Yang

Cc: stable On 2025/5/28 19:42, Lance Yang wrote: > > Thanks for taking the time to review! > > On 2025/5/28 19:05, Florian Westphal wrote: >> Lance Yang <ioworker0(a)gmail.com> wrote: >>> From: Lance Yang <lance.yang(a)linux.dev> >>> >>> When no logger is registered, nf_conntrack_log_invalid fails to log >>> invalid >>> packets, leaving users unaware of actual invalid traffic. Improve >>> this by >>> loading nf_log_syslog, similar to how 'iptables -I FORWARD 1 -m >>> conntrack >>> --ctstate INVALID -j LOG' triggers it. >> >> Acked-by: Florian Westphal <fw(a)strlen.de> > > Hmm... should this patch be backported to stable kernels? Without it, > nf_conntrack_log_invalid won't log invalid packets when no logger is > registered, causing unnecessary debugging effort ;) > > Back then, I actually thought my machine wasn't seeing any invalid > packets... turns out they just weren't logged in dmesg :( > > Thanks, > Lance

3 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025