May 2025 - Linux-stable-mirror

[PATCH AUTOSEL 6.6 01/18] 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

1 month

1
17
0 0

[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

1 month

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

1 month

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

1 month

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

1 month

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

1 month

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.”

1 month

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(-)

1 month

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

1 month

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

1 month

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

1 month

1
0
0 0

KASAN: slab-out-of-bounds Read in steelseries_remove in linux6.12-6.15

by Jianzhou Zhao

Hello, I found a potential bug titled " KASAN: slab-out-of-bounds Read in steelseries_remove " with modified syzkaller in the Linux6.12 - 6.15. This bug was verified to exist in 6.12.24,6.12.28 and 6.15. During the execution of poc, for the same hdev device, in the function steelseries_probe, the sd of hdev is first set to the steelseries_device type. If sd->quriks=0x1, Then execute steelseries_srws1_probe to reset the sd of hdev to the type steelseries_srws1_data. However, when the device is removed and the steelseries_remove command is executed, the sd obtained through hdev will first be forcibly converted to the steelseries_device type, but the value of sd->quirks may not be 0x1, but rather become some pointer. For example, sd->quirks=0xffff888022167000, then steelseries_srws1_remove (hdev) cannot be executed. This will lead to type errors in subsequent access to sd (wrongly treating sd of type steelseries_srws1_data as of type steelseries_device), and an out-of-bounds access error occurs when accessing sd->lock. However, I still don't understand why the sd-> quirks of the same hdev in the detection phase and the deletion phase are completely inconsistent (even Pointers appear). static int steelseries_probe(struct hid_device *hdev, const struct hid_device_id *id) { struct steelseries_device *sd; int ret; sd = devm_kzalloc(&hdev->dev, sizeof(*sd), GFP_KERNEL); ....... hid_set_drvdata(hdev, sd); [1] Set hdev->dev->driver_data to the type of steelseries_device ( hdev->dev->driver_data = sd ) sd->hdev = hdev; sd->quirks = id->driver_data; //Here, sd->quirks is assigned a value of 0x1 if (sd->quirks & STEELSERIES_SRWS1) { //Passed the inspection successfully #if IS_BUILTIN(CONFIG_LEDS_CLASS) || \ (IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES)) return steelseries_srws1_probe(hdev, id); [2] Set hdev->dev->driver_data to the type of steelseries_srws1_data #else return -ENODEV; #endif } ...... } static int steelseries_srws1_probe(struct hid_device *hdev, const struct hid_device_id *id) { int ret, i; struct led_classdev *led; size_t name_sz; char *name; struct steelseries_srws1_data *drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL); if (drv_data == NULL) { hid_err(hdev, "can't alloc SRW-S1 memory\n"); return -ENOMEM; } hid_set_drvdata(hdev, drv_data); [3] Set hdev->dev->driver_data to the type of steelseries_srws1_data } static void steelseries_remove(struct hid_device *hdev) { struct steelseries_device *sd = hid_get_drvdata(hdev); [4] The default sd is of the steelseries_device type unsigned long flags; if (sd->quirks & STEELSERIES_SRWS1) { [5]sd->quriks is not 0x1 but equal to the value of a pointer, such as 0xffff888022167000. Therefore, the inspection cannot be passed and steelseries_srws1_remove cannot be executed #if IS_BUILTIN(CONFIG_LEDS_CLASS) || \ (IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES)) steelseries_srws1_remove(hdev); #endif return; } spin_lock_irqsave(&sd->lock, flags); [6] The correct type of sd is steelseries_srws1_data. However, here, sd is treated as the type of steelseries_srws1_data to access sd->quirks, resulting in out-of-bounds access ...... } The commit of the kernel is : ef4999852d307d38cfdecd91ed6892cc03beb9b8 kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=55f8591b98dd132 compiler: gcc version 11.4.0 If you fix this issue, please add the following tag to the commit: Reported-by: Jianzhou Zhao <luckd0g(a)163.com> Reported-by: Penglei Jiang <superman.xpt(a)gmail.com> I put the reproduction program of this bug at the end of the email. ------------[ cut here ]----------------------------------------- TITLE: KASAN: slab-out-of-bounds Read in steelseries_remove ------------[ cut here ]------------ ================================================================== BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x31b5/0x3f40 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880285a64d0 by task kworker/0:11/12464 CPU: 0 UID: 0 PID: 12464 Comm: kworker/0:11 Not tainted 6.12.28 #29 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc6/0x620 mm/kasan/report.c:488 kasan_report+0xd8/0x110 mm/kasan/report.c:601 __lock_acquire+0x31b5/0x3f40 kernel/locking/lockdep.c:5065 lock_acquire.part.0+0x11f/0x380 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162 steelseries_remove+0x8c/0x1f0 drivers/hid/hid-steelseries.c:564 hid_device_remove+0xce/0x260 drivers/hid/hid-core.c:2758 device_remove+0xc8/0x170 drivers/base/dd.c:567 __device_release_driver drivers/base/dd.c:1272 [inline] device_release_driver_internal+0x44b/0x620 drivers/base/dd.c:1295 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x377/0x9c0 drivers/base/core.c:3881 hid_remove_device drivers/hid/hid-core.c:2942 [inline] hid_destroy_device+0xe5/0x150 drivers/hid/hid-core.c:2962 usbhid_disconnect+0xa0/0xe0 drivers/hid/usbhid/hid-core.c:1459 usb_unbind_interface+0x1e8/0x960 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:569 [inline] device_remove+0x122/0x170 drivers/base/dd.c:561 __device_release_driver drivers/base/dd.c:1272 [inline] device_release_driver_internal+0x44b/0x620 drivers/base/dd.c:1295 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x377/0x9c0 drivers/base/core.c:3881 usb_disable_device+0x35f/0x7c0 drivers/usb/core/message.c:1418 usb_disconnect+0x2e0/0x920 drivers/usb/core/hub.c:2315 hub_port_connect drivers/usb/core/hub.c:5373 [inline] hub_port_connect_change drivers/usb/core/hub.c:5673 [inline] port_event drivers/usb/core/hub.c:5833 [inline] hub_event+0x1da4/0x4e20 drivers/usb/core/hub.c:5915 process_one_work+0x9c3/0x1b70 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x61e/0xe40 kernel/workqueue.c:3391 kthread+0x2ab/0x390 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2285: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] steelseries_srws1_probe drivers/hid/hid-steelseries.c:253 [inline] steelseries_probe+0x69d/0xf60 drivers/hid/hid-steelseries.c:528 __hid_device_probe drivers/hid/hid-core.c:2702 [inline] hid_device_probe+0x2f5/0x4f0 drivers/hid/hid-core.c:2739 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 hid_add_device+0x377/0xa60 drivers/hid/hid-core.c:2885 usbhid_probe+0xd41/0x1400 drivers/hid/usbhid/hid-core.c:1432 usb_probe_interface+0x309/0x9d0 drivers/usb/core/driver.c:399 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 usb_set_configuration+0x120e/0x1e10 drivers/usb/core/message.c:2210 usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:254 usb_probe_device+0xec/0x3e0 drivers/usb/core/driver.c:294 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 usb_new_device+0xd04/0x19d0 drivers/usb/core/hub.c:2662 hub_port_connect drivers/usb/core/hub.c:5533 [inline] hub_port_connect_change drivers/usb/core/hub.c:5673 [inline] port_event drivers/usb/core/hub.c:5833 [inline] hub_event+0x2d92/0x4e20 drivers/usb/core/hub.c:5915 process_one_work+0x9c3/0x1b70 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x61e/0xe40 kernel/workqueue.c:3391 kthread+0x2ab/0x390 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the object at ffff8880285a6400 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 72 bytes to the right of allocated 136-byte region [ffff8880285a6400, ffff8880285a6488) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x285a6 ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 00fff00000000000 ffff88801b0413c0 ffffea0000875540 dead000000000003 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 9743, tgid 9743 (syz-executor), ts 61586032132, free_ts 61073188909 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x2f0/0x350 mm/page_alloc.c:1558 prep_new_page mm/page_alloc.c:1566 [inline] get_page_from_freelist+0x7d6/0x3660 mm/page_alloc.c:3476 __alloc_pages_noprof+0x229/0x2670 mm/page_alloc.c:4754 alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269 alloc_slab_page mm/slub.c:2425 [inline] allocate_slab mm/slub.c:2595 [inline] new_slab+0x2df/0x410 mm/slub.c:2649 ___slab_alloc+0xe2f/0x19a0 mm/slub.c:3837 __slab_alloc.isra.0+0x56/0xb0 mm/slub.c:3927 __slab_alloc_node mm/slub.c:3980 [inline] slab_alloc_node mm/slub.c:4141 [inline] __kmalloc_cache_noprof+0x2b4/0x300 mm/slub.c:4309 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] call_usermodehelper_setup+0xaf/0x360 kernel/umh.c:363 kobject_uevent_env+0x15fe/0x1860 lib/kobject_uevent.c:628 rx_queue_add_kobject net/core/net-sysfs.c:1124 [inline] net_rx_queue_update_kobjects+0x17c/0x5f0 net/core/net-sysfs.c:1164 register_queue_kobjects net/core/net-sysfs.c:1898 [inline] netdev_register_kobject+0x269/0x3a0 net/core/net-sysfs.c:2143 register_netdevice+0x1312/0x1db0 net/core/dev.c:10557 veth_newlink+0x354/0x9e0 drivers/net/veth.c:1830 rtnl_newlink_create net/core/rtnetlink.c:3542 [inline] __rtnl_newlink+0x1187/0x1910 net/core/rtnetlink.c:3762 rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3775 page last free pid 9715 tgid 9715 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1127 [inline] free_unref_page+0x6d7/0x1080 mm/page_alloc.c:2659 qlink_free mm/kasan/quarantine.c:163 [inline] qlist_free_all+0x54/0x120 mm/kasan/quarantine.c:179 kasan_quarantine_reduce+0x192/0x1e0 mm/kasan/quarantine.c:286 __kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:329 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] __kmalloc_cache_noprof+0x11e/0x300 mm/slub.c:4309 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] kobject_uevent_env+0x265/0x1860 lib/kobject_uevent.c:540 __kobject_del+0x168/0x1f0 lib/kobject.c:601 kobject_cleanup lib/kobject.c:680 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x327/0x5a0 lib/kobject.c:737 net_rx_queue_update_kobjects+0x476/0x5f0 net/core/net-sysfs.c:1178 netif_set_real_num_rx_queues+0x169/0x210 net/core/dev.c:3055 veth_init_queues+0x151/0x190 drivers/net/veth.c:1761 veth_newlink+0x530/0x9e0 drivers/net/veth.c:1873 rtnl_newlink_create net/core/rtnetlink.c:3542 [inline] __rtnl_newlink+0x1187/0x1910 net/core/rtnetlink.c:3762 rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3775 rtnetlink_rcv_msg+0x3c7/0xea0 net/core/rtnetlink.c:6678 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2537 Memory state around the buggy address: ffff8880285a6380: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ffff8880285a6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880285a6480: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8880285a6500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880285a6580: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ================================================================== // autogenerated by syzkaller (https://github.com/google/syzkaller) #define _GNU_SOURCE #include <dirent.h> #include <endian.h> #include <errno.h> #include <fcntl.h> #include <signal.h> #include <stdarg.h> #include <stdbool.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mount.h> #include <sys/prctl.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> #include <time.h> #include <unistd.h> #include <linux/usb/ch9.h> static unsigned long long procid; static void sleep_ms(uint64_t ms) { usleep(ms * 1000); } static uint64_t current_time_ms(void) { struct timespec ts; if (clock_gettime(CLOCK_MONOTONIC, &ts)) exit(1); return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000; } static bool write_file(const char* file, const char* what, ...) { char buf[1024]; va_list args; va_start(args, what); vsnprintf(buf, sizeof(buf), what, args); va_end(args); buf[sizeof(buf) - 1] = 0; int len = strlen(buf); int fd = open(file, O_WRONLY | O_CLOEXEC); if (fd == -1) return false; if (write(fd, buf, len) != len) { int err = errno; close(fd); errno = err; return false; } close(fd); return true; } #define MAX_FDS 30 #define USB_MAX_IFACE_NUM 4 #define USB_MAX_EP_NUM 32 #define USB_MAX_FDS 6 struct usb_endpoint_index { struct usb_endpoint_descriptor desc; int handle; }; struct usb_iface_index { struct usb_interface_descriptor* iface; uint8_t bInterfaceNumber; uint8_t bAlternateSetting; uint8_t bInterfaceClass; struct usb_endpoint_index eps[USB_MAX_EP_NUM]; int eps_num; }; struct usb_device_index { struct usb_device_descriptor* dev; struct usb_config_descriptor* config; uint8_t bDeviceClass; uint8_t bMaxPower; int config_length; struct usb_iface_index ifaces[USB_MAX_IFACE_NUM]; int ifaces_num; int iface_cur; }; struct usb_info { int fd; struct usb_device_index index; }; static struct usb_info usb_devices[USB_MAX_FDS]; static struct usb_device_index* lookup_usb_index(int fd) { for (int i = 0; i < USB_MAX_FDS; i++) { if (__atomic_load_n(&usb_devices[i].fd, __ATOMIC_ACQUIRE) == fd) return &usb_devices[i].index; } return NULL; } static int usb_devices_num; static bool parse_usb_descriptor(const char* buffer, size_t length, struct usb_device_index* index) { if (length < sizeof(*index->dev) + sizeof(*index->config)) return false; memset(index, 0, sizeof(*index)); index->dev = (struct usb_device_descriptor*)buffer; index->config = (struct usb_config_descriptor*)(buffer + sizeof(*index->dev)); index->bDeviceClass = index->dev->bDeviceClass; index->bMaxPower = index->config->bMaxPower; index->config_length = length - sizeof(*index->dev); index->iface_cur = -1; size_t offset = 0; while (true) { if (offset + 1 >= length) break; uint8_t desc_length = buffer[offset]; uint8_t desc_type = buffer[offset + 1]; if (desc_length <= 2) break; if (offset + desc_length > length) break; if (desc_type == USB_DT_INTERFACE && index->ifaces_num < USB_MAX_IFACE_NUM) { struct usb_interface_descriptor* iface = (struct usb_interface_descriptor*)(buffer + offset); index->ifaces[index->ifaces_num].iface = iface; index->ifaces[index->ifaces_num].bInterfaceNumber = iface->bInterfaceNumber; index->ifaces[index->ifaces_num].bAlternateSetting = iface->bAlternateSetting; index->ifaces[index->ifaces_num].bInterfaceClass = iface->bInterfaceClass; index->ifaces_num++; } if (desc_type == USB_DT_ENDPOINT && index->ifaces_num > 0) { struct usb_iface_index* iface = &index->ifaces[index->ifaces_num - 1]; if (iface->eps_num < USB_MAX_EP_NUM) { memcpy(&iface->eps[iface->eps_num].desc, buffer + offset, sizeof(iface->eps[iface->eps_num].desc)); iface->eps_num++; } } offset += desc_length; } return true; } static struct usb_device_index* add_usb_index(int fd, const char* dev, size_t dev_len) { int i = __atomic_fetch_add(&usb_devices_num, 1, __ATOMIC_RELAXED); if (i >= USB_MAX_FDS) return NULL; if (!parse_usb_descriptor(dev, dev_len, &usb_devices[i].index)) return NULL; __atomic_store_n(&usb_devices[i].fd, fd, __ATOMIC_RELEASE); return &usb_devices[i].index; } struct vusb_connect_string_descriptor { uint32_t len; char* str; } __attribute__((packed)); struct vusb_connect_descriptors { uint32_t qual_len; char* qual; uint32_t bos_len; char* bos; uint32_t strs_len; struct vusb_connect_string_descriptor strs[0]; } __attribute__((packed)); static const char default_string[] = { 8, USB_DT_STRING, 's', 0, 'y', 0, 'z', 0 }; static const char default_lang_id[] = { 4, USB_DT_STRING, 0x09, 0x04 }; static bool lookup_connect_response_in(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, struct usb_qualifier_descriptor* qual, char** response_data, uint32_t* response_length) { struct usb_device_index* index = lookup_usb_index(fd); uint8_t str_idx; if (!index) return false; switch (ctrl->bRequestType & USB_TYPE_MASK) { case USB_TYPE_STANDARD: switch (ctrl->bRequest) { case USB_REQ_GET_DESCRIPTOR: switch (ctrl->wValue >> 8) { case USB_DT_DEVICE: *response_data = (char*)index->dev; *response_length = sizeof(*index->dev); return true; case USB_DT_CONFIG: *response_data = (char*)index->config; *response_length = index->config_length; return true; case USB_DT_STRING: str_idx = (uint8_t)ctrl->wValue; if (descs && str_idx < descs->strs_len) { *response_data = descs->strs[str_idx].str; *response_length = descs->strs[str_idx].len; return true; } if (str_idx == 0) { *response_data = (char*)&default_lang_id[0]; *response_length = default_lang_id[0]; return true; } *response_data = (char*)&default_string[0]; *response_length = default_string[0]; return true; case USB_DT_BOS: *response_data = descs->bos; *response_length = descs->bos_len; return true; case USB_DT_DEVICE_QUALIFIER: if (!descs->qual) { qual->bLength = sizeof(*qual); qual->bDescriptorType = USB_DT_DEVICE_QUALIFIER; qual->bcdUSB = index->dev->bcdUSB; qual->bDeviceClass = index->dev->bDeviceClass; qual->bDeviceSubClass = index->dev->bDeviceSubClass; qual->bDeviceProtocol = index->dev->bDeviceProtocol; qual->bMaxPacketSize0 = index->dev->bMaxPacketSize0; qual->bNumConfigurations = index->dev->bNumConfigurations; qual->bRESERVED = 0; *response_data = (char*)qual; *response_length = sizeof(*qual); return true; } *response_data = descs->qual; *response_length = descs->qual_len; return true; default: break; } break; default: break; } break; default: break; } return false; } typedef bool (*lookup_connect_out_response_t)(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, bool* done); static bool lookup_connect_response_out_generic(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, bool* done) { switch (ctrl->bRequestType & USB_TYPE_MASK) { case USB_TYPE_STANDARD: switch (ctrl->bRequest) { case USB_REQ_SET_CONFIGURATION: *done = true; return true; default: break; } break; } return false; } struct vusb_descriptor { uint8_t req_type; uint8_t desc_type; uint32_t len; char data[0]; } __attribute__((packed)); struct vusb_descriptors { uint32_t len; struct vusb_descriptor* generic; struct vusb_descriptor* descs[0]; } __attribute__((packed)); struct vusb_response { uint8_t type; uint8_t req; uint32_t len; char data[0]; } __attribute__((packed)); struct vusb_responses { uint32_t len; struct vusb_response* generic; struct vusb_response* resps[0]; } __attribute__((packed)); static bool lookup_control_response(const struct vusb_descriptors* descs, const struct vusb_responses* resps, struct usb_ctrlrequest* ctrl, char** response_data, uint32_t* response_length) { int descs_num = 0; int resps_num = 0; if (descs) descs_num = (descs->len - offsetof(struct vusb_descriptors, descs)) / sizeof(descs->descs[0]); if (resps) resps_num = (resps->len - offsetof(struct vusb_responses, resps)) / sizeof(resps->resps[0]); uint8_t req = ctrl->bRequest; uint8_t req_type = ctrl->bRequestType & USB_TYPE_MASK; uint8_t desc_type = ctrl->wValue >> 8; if (req == USB_REQ_GET_DESCRIPTOR) { int i; for (i = 0; i < descs_num; i++) { struct vusb_descriptor* desc = descs->descs[i]; if (!desc) continue; if (desc->req_type == req_type && desc->desc_type == desc_type) { *response_length = desc->len; if (*response_length != 0) *response_data = &desc->data[0]; else *response_data = NULL; return true; } } if (descs && descs->generic) { *response_data = &descs->generic->data[0]; *response_length = descs->generic->len; return true; } } else { int i; for (i = 0; i < resps_num; i++) { struct vusb_response* resp = resps->resps[i]; if (!resp) continue; if (resp->type == req_type && resp->req == req) { *response_length = resp->len; if (*response_length != 0) *response_data = &resp->data[0]; else *response_data = NULL; return true; } } if (resps && resps->generic) { *response_data = &resps->generic->data[0]; *response_length = resps->generic->len; return true; } } return false; } #define UDC_NAME_LENGTH_MAX 128 struct usb_raw_init { __u8 driver_name[UDC_NAME_LENGTH_MAX]; __u8 device_name[UDC_NAME_LENGTH_MAX]; __u8 speed; }; enum usb_raw_event_type { USB_RAW_EVENT_INVALID = 0, USB_RAW_EVENT_CONNECT = 1, USB_RAW_EVENT_CONTROL = 2, }; struct usb_raw_event { __u32 type; __u32 length; __u8 data[0]; }; struct usb_raw_ep_io { __u16 ep; __u16 flags; __u32 length; __u8 data[0]; }; #define USB_RAW_EPS_NUM_MAX 30 #define USB_RAW_EP_NAME_MAX 16 #define USB_RAW_EP_ADDR_ANY 0xff struct usb_raw_ep_caps { __u32 type_control : 1; __u32 type_iso : 1; __u32 type_bulk : 1; __u32 type_int : 1; __u32 dir_in : 1; __u32 dir_out : 1; }; struct usb_raw_ep_limits { __u16 maxpacket_limit; __u16 max_streams; __u32 reserved; }; struct usb_raw_ep_info { __u8 name[USB_RAW_EP_NAME_MAX]; __u32 addr; struct usb_raw_ep_caps caps; struct usb_raw_ep_limits limits; }; struct usb_raw_eps_info { struct usb_raw_ep_info eps[USB_RAW_EPS_NUM_MAX]; }; #define USB_RAW_IOCTL_INIT _IOW('U', 0, struct usb_raw_init) #define USB_RAW_IOCTL_RUN _IO('U', 1) #define USB_RAW_IOCTL_EVENT_FETCH _IOR('U', 2, struct usb_raw_event) #define USB_RAW_IOCTL_EP0_WRITE _IOW('U', 3, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP0_READ _IOWR('U', 4, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP_ENABLE _IOW('U', 5, struct usb_endpoint_descriptor) #define USB_RAW_IOCTL_EP_DISABLE _IOW('U', 6, __u32) #define USB_RAW_IOCTL_EP_WRITE _IOW('U', 7, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP_READ _IOWR('U', 8, struct usb_raw_ep_io) #define USB_RAW_IOCTL_CONFIGURE _IO('U', 9) #define USB_RAW_IOCTL_VBUS_DRAW _IOW('U', 10, __u32) #define USB_RAW_IOCTL_EPS_INFO _IOR('U', 11, struct usb_raw_eps_info) #define USB_RAW_IOCTL_EP0_STALL _IO('U', 12) #define USB_RAW_IOCTL_EP_SET_HALT _IOW('U', 13, __u32) #define USB_RAW_IOCTL_EP_CLEAR_HALT _IOW('U', 14, __u32) #define USB_RAW_IOCTL_EP_SET_WEDGE _IOW('U', 15, __u32) static int usb_raw_open() { return open("/dev/raw-gadget", O_RDWR); } static int usb_raw_init(int fd, uint32_t speed, const char* driver, const char* device) { struct usb_raw_init arg; strncpy((char*)&arg.driver_name[0], driver, sizeof(arg.driver_name)); strncpy((char*)&arg.device_name[0], device, sizeof(arg.device_name)); arg.speed = speed; return ioctl(fd, USB_RAW_IOCTL_INIT, &arg); } static int usb_raw_run(int fd) { return ioctl(fd, USB_RAW_IOCTL_RUN, 0); } static int usb_raw_configure(int fd) { return ioctl(fd, USB_RAW_IOCTL_CONFIGURE, 0); } static int usb_raw_vbus_draw(int fd, uint32_t power) { return ioctl(fd, USB_RAW_IOCTL_VBUS_DRAW, power); } static int usb_raw_ep0_write(int fd, struct usb_raw_ep_io* io) { return ioctl(fd, USB_RAW_IOCTL_EP0_WRITE, io); } static int usb_raw_ep0_read(int fd, struct usb_raw_ep_io* io) { return ioctl(fd, USB_RAW_IOCTL_EP0_READ, io); } static int usb_raw_event_fetch(int fd, struct usb_raw_event* event) { return ioctl(fd, USB_RAW_IOCTL_EVENT_FETCH, event); } static int usb_raw_ep_enable(int fd, struct usb_endpoint_descriptor* desc) { return ioctl(fd, USB_RAW_IOCTL_EP_ENABLE, desc); } static int usb_raw_ep_disable(int fd, int ep) { return ioctl(fd, USB_RAW_IOCTL_EP_DISABLE, ep); } static int usb_raw_ep0_stall(int fd) { return ioctl(fd, USB_RAW_IOCTL_EP0_STALL, 0); } static int lookup_interface(int fd, uint8_t bInterfaceNumber, uint8_t bAlternateSetting) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return -1; for (int i = 0; i < index->ifaces_num; i++) { if (index->ifaces[i].bInterfaceNumber == bInterfaceNumber && index->ifaces[i].bAlternateSetting == bAlternateSetting) return i; } return -1; } #define USB_MAX_PACKET_SIZE 4096 struct usb_raw_control_event { struct usb_raw_event inner; struct usb_ctrlrequest ctrl; char data[USB_MAX_PACKET_SIZE]; }; struct usb_raw_ep_io_data { struct usb_raw_ep_io inner; char data[USB_MAX_PACKET_SIZE]; }; static void set_interface(int fd, int n) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return; if (index->iface_cur >= 0 && index->iface_cur < index->ifaces_num) { for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++) { int rv = usb_raw_ep_disable(fd, index->ifaces[index->iface_cur].eps[ep].handle); if (rv < 0) { } else { } } } if (n >= 0 && n < index->ifaces_num) { for (int ep = 0; ep < index->ifaces[n].eps_num; ep++) { int rv = usb_raw_ep_enable(fd, &index->ifaces[n].eps[ep].desc); if (rv < 0) { } else { index->ifaces[n].eps[ep].handle = rv; } } index->iface_cur = n; } } static int configure_device(int fd) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return -1; int rv = usb_raw_vbus_draw(fd, index->bMaxPower); if (rv < 0) { return rv; } rv = usb_raw_configure(fd); if (rv < 0) { return rv; } set_interface(fd, 0); return 0; } static volatile long syz_usb_connect_impl(uint64_t speed, uint64_t dev_len, const char* dev, const struct vusb_connect_descriptors* descs, lookup_connect_out_response_t lookup_connect_response_out) { if (!dev) { return -1; } int fd = usb_raw_open(); if (fd < 0) { return fd; } if (fd >= MAX_FDS) { close(fd); return -1; } struct usb_device_index* index = add_usb_index(fd, dev, dev_len); if (!index) { return -1; } char device[32]; sprintf(&device[0], "dummy_udc.%llu", procid); int rv = usb_raw_init(fd, speed, "dummy_udc", &device[0]); if (rv < 0) { return rv; } rv = usb_raw_run(fd); if (rv < 0) { return rv; } bool done = false; while (!done) { struct usb_raw_control_event event; event.inner.type = 0; event.inner.length = sizeof(event.ctrl); rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event); if (rv < 0) { return rv; } if (event.inner.type != USB_RAW_EVENT_CONTROL) continue; char* response_data = NULL; uint32_t response_length = 0; struct usb_qualifier_descriptor qual; if (event.ctrl.bRequestType & USB_DIR_IN) { if (!lookup_connect_response_in(fd, descs, &event.ctrl, &qual, &response_data, &response_length)) { usb_raw_ep0_stall(fd); continue; } } else { if (!lookup_connect_response_out(fd, descs, &event.ctrl, &done)) { usb_raw_ep0_stall(fd); continue; } response_data = NULL; response_length = event.ctrl.wLength; } if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD && event.ctrl.bRequest == USB_REQ_SET_CONFIGURATION) { rv = configure_device(fd); if (rv < 0) { return rv; } } struct usb_raw_ep_io_data response; response.inner.ep = 0; response.inner.flags = 0; if (response_length > sizeof(response.data)) response_length = 0; if (event.ctrl.wLength < response_length) response_length = event.ctrl.wLength; response.inner.length = response_length; if (response_data) memcpy(&response.data[0], response_data, response_length); else memset(&response.data[0], 0, response_length); if (event.ctrl.bRequestType & USB_DIR_IN) { rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response); } else { rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response); } if (rv < 0) { return rv; } } sleep_ms(200); return fd; } static volatile long syz_usb_connect(volatile long a0, volatile long a1, volatile long a2, volatile long a3) { uint64_t speed = a0; uint64_t dev_len = a1; const char* dev = (const char*)a2; const struct vusb_connect_descriptors* descs = (const struct vusb_connect_descriptors*)a3; return syz_usb_connect_impl(speed, dev_len, dev, descs, &lookup_connect_response_out_generic); } static volatile long syz_usb_control_io(volatile long a0, volatile long a1, volatile long a2) { int fd = a0; const struct vusb_descriptors* descs = (const struct vusb_descriptors*)a1; const struct vusb_responses* resps = (const struct vusb_responses*)a2; struct usb_raw_control_event event; event.inner.type = 0; event.inner.length = USB_MAX_PACKET_SIZE; int rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event); if (rv < 0) { return rv; } if (event.inner.type != USB_RAW_EVENT_CONTROL) { return -1; } char* response_data = NULL; uint32_t response_length = 0; if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) { if (!lookup_control_response(descs, resps, &event.ctrl, &response_data, &response_length)) { usb_raw_ep0_stall(fd); return -1; } } else { if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD || event.ctrl.bRequest == USB_REQ_SET_INTERFACE) { int iface_num = event.ctrl.wIndex; int alt_set = event.ctrl.wValue; int iface_index = lookup_interface(fd, iface_num, alt_set); if (iface_index < 0) { } else { set_interface(fd, iface_index); } } response_length = event.ctrl.wLength; } struct usb_raw_ep_io_data response; response.inner.ep = 0; response.inner.flags = 0; if (response_length > sizeof(response.data)) response_length = 0; if (event.ctrl.wLength < response_length) response_length = event.ctrl.wLength; if ((event.ctrl.bRequestType & USB_DIR_IN) && !event.ctrl.wLength) { response_length = USB_MAX_PACKET_SIZE; } response.inner.length = response_length; if (response_data) memcpy(&response.data[0], response_data, response_length); else memset(&response.data[0], 0, response_length); if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) { rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response); } else { rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response); } if (rv < 0) { return rv; } sleep_ms(200); return 0; } static void kill_and_wait(int pid, int* status) { kill(-pid, SIGKILL); kill(pid, SIGKILL); for (int i = 0; i < 100; i++) { if (waitpid(-1, status, WNOHANG | __WALL) == pid) return; usleep(1000); } DIR* dir = opendir("/sys/fs/fuse/connections"); if (dir) { for (;;) { struct dirent* ent = readdir(dir); if (!ent) break; if (strcmp(ent->d_name, ".") == 0 || strcmp(ent->d_name, "..") == 0) continue; char abort[300]; snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort", ent->d_name); int fd = open(abort, O_WRONLY); if (fd == -1) { continue; } if (write(fd, abort, 1) < 0) { } close(fd); } closedir(dir); } else { } while (waitpid(-1, status, __WALL) != pid) { } } static void setup_test() { prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0); setpgrp(); write_file("/proc/self/oom_score_adj", "1000"); } static void execute_one(void); #define WAIT_FLAGS __WALL static void loop(void) { int iter = 0; for (;; iter++) { int pid = fork(); if (pid < 0) exit(1); if (pid == 0) { setup_test(); execute_one(); exit(0); } int status = 0; uint64_t start = current_time_ms(); for (;;) { sleep_ms(10); if (waitpid(-1, &status, WNOHANG | WAIT_FLAGS) == pid) break; if (current_time_ms() - start < 5000) continue; kill_and_wait(pid, &status); break; } } } uint64_t r[1] = {0xffffffffffffffff}; void execute_one(void) { intptr_t res = 0; if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {} *(uint8_t*)0x200000000040 = 0x12; *(uint8_t*)0x200000000041 = 1; *(uint16_t*)0x200000000042 = 0x200; *(uint8_t*)0x200000000044 = 0; *(uint8_t*)0x200000000045 = 0; *(uint8_t*)0x200000000046 = 0; *(uint8_t*)0x200000000047 = 8; *(uint16_t*)0x200000000048 = 0x1038; *(uint16_t*)0x20000000004a = 0x1410; *(uint16_t*)0x20000000004c = 0; *(uint8_t*)0x20000000004e = 0; *(uint8_t*)0x20000000004f = 0; *(uint8_t*)0x200000000050 = 0; *(uint8_t*)0x200000000051 = 1; *(uint8_t*)0x200000000052 = 9; *(uint8_t*)0x200000000053 = 2; *(uint16_t*)0x200000000054 = 0x24; *(uint8_t*)0x200000000056 = 1; *(uint8_t*)0x200000000057 = 0; *(uint8_t*)0x200000000058 = 0; *(uint8_t*)0x200000000059 = 0; *(uint8_t*)0x20000000005a = 2; *(uint8_t*)0x20000000005b = 9; *(uint8_t*)0x20000000005c = 4; *(uint8_t*)0x20000000005d = 0; *(uint8_t*)0x20000000005e = 0; *(uint8_t*)0x20000000005f = 1; *(uint8_t*)0x200000000060 = 3; *(uint8_t*)0x200000000061 = 0; *(uint8_t*)0x200000000062 = 1; *(uint8_t*)0x200000000063 = 0; *(uint8_t*)0x200000000064 = 9; *(uint8_t*)0x200000000065 = 0x21; *(uint16_t*)0x200000000066 = 8; *(uint8_t*)0x200000000068 = 0xfd; *(uint8_t*)0x200000000069 = 1; *(uint8_t*)0x20000000006a = 0x22; *(uint16_t*)0x20000000006b = 0x29; *(uint8_t*)0x20000000006d = 9; *(uint8_t*)0x20000000006e = 5; *(uint8_t*)0x20000000006f = 0x81; *(uint8_t*)0x200000000070 = 3; *(uint16_t*)0x200000000071 = 0; *(uint8_t*)0x200000000073 = 0; *(uint8_t*)0x200000000074 = 0; *(uint8_t*)0x200000000075 = 0; res = -1; res = syz_usb_connect(/*speed=*/0, /*dev_len=*/0x36, /*dev=*/0x200000000040, /*conn_descs=*/0); if (res != -1) r[0] = res; syz_usb_control_io(/*fd=*/r[0], /*descs=*/0, /*resps=*/0); syscall(__NR_prctl, /*option=*/0x26ul, /*arg=*/1ul, 0, 0, 0); *(uint32_t*)0x200000000000 = 0x2c; *(uint64_t*)0x200000000004 = 0x2000000000c0; memcpy((void*)0x2000000000c0, "\x40\x0c\x2a\x00\x00\x00\x2a\x22\x5f\xab\xe9\x36\x24\xdb\xb2\x2d\x8b\x5a\xc8\x50\x1c\x70\x40\xb2\xad\xcf\x1f\xb3\xab\x7e\xd1\x6b\xbb\xbf\xa2\xa0\x80\x2a\x9e\x3f\x78\x95\xe5\x90\x2e\xdd\xcb\x54", 48); *(uint64_t*)0x20000000000c = 0; *(uint64_t*)0x200000000014 = 0; *(uint64_t*)0x20000000001c = 0; *(uint64_t*)0x200000000024 = 0; syz_usb_control_io(/*fd=*/r[0], /*descs=*/0x200000000000, /*resps=*/0); } int main(void) { syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); const char* reason; (void)reason; loop(); return 0; } I hope it helps. Best regards Jianzhou Zhao Penglei Jiang

1 month

1
0
0 0

Qualcomm Supply Chain - Sinldo Technology

by Alan Ye

[Sinldo Technology] Company Profile Hong Kong Sinldo Technology Co., Ltd. was established in 2009 and focuses on the supply chain of Qualcomm chips. As a leading supplier in the industry, We have established solid cooperative relationships with many internationally renowned manufacturers and are committed to providing customers with high-quality and reliable chip products. Business Scope： Import and distribution of Qualcomm chips Management and bidding for excess electronic components Provide high-quality customer service and technical support Mission Stable supply Vision Mutual benefit and Triumph Value Reduce Fees and increase efficiency Environment The company is located in the core business district, with convenient transportation, elegant environment and complete surrounding supporting facilities, which facilitates the travel and business exchanges of employees and customers. Milestones 2025 2020 2015 2009 It is expected to complete the upgrade strategic planning, further increase market share, and strive for sustainable development The company implemented a digital management system and began to actively develop online Deals channels The company has added multiple 4G Qualcomm chips and established partnerships with more OEM customers。 The company was formally established in Shenzhen and initially established cooperative relationships with global suppliers Company Environment Coastal Huanqing Building Office Area storehouse [Qualcomm]Company Spot [ WIFI6 - IPQ5018 Kits ] IPQ5018-0-MRQFN232-MT-01-0 QCN6102-0-DRQFN116-TR-01-0 QCA8337-AL3C Snapdragon SDM-450-B Kits SDM-450-B-792NSP-TR-01-0-AA WTR-2965-0-59F0WNSP-TR-07-1 PMI-8952-0-144WLNSP-TR-02-0-00 WCN-3680B-0-79BWLNSP-TR-05-1 PM-8953-0-187F0WNSP-TR-01-1 MDM9x07 Kits MDM-9607-0-328PSP-TR-00-0 MDM-9207-0-328PSP-TR-00-0 WTR-2965-0-59F0WNSP-TR-07-1 PMD-9607-0-94WLNSP-TR-04-2 [Sinldo Technology Co., Ltd.] Email：yesunjian888(a)gmail.com Skype：625285556(a)qq.com Address：Room 2305, Hai'an Huanqing Building, Futian Road, Futian District, Shenzhen Wechat Hit subscribe now to receive regular updates and our product’s latest features! Subscribe If you don't want to receive our emails, you can easily unsubscribe here. Alan Ye Purchasing Manager ：+86 136 0651 6680 QUALCOMM Supply chain : yesunjian888(a)gmail.com

1 month

1
0
0 0

FAILED: patch "[PATCH] smb: client: Fix use-after-free in cifs_fill_dirent" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x a7a8fe56e932a36f43e031b398aef92341bf5ea0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052437-platform-elastic-f5d2@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a7a8fe56e932a36f43e031b398aef92341bf5ea0 Mon Sep 17 00:00:00 2001 From: Wang Zhaolong <wangzhaolong1(a)huawei.com> Date: Fri, 16 May 2025 17:12:55 +0800 Subject: [PATCH] smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK> Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------------------------------------- cifs_readdir /* file->private_data == NULL */ initiate_cifs_search cifsFile = kzalloc(sizeof(struct cifsFileInfo), GFP_KERNEL); smb2_query_dir_first ->query_dir_first() SMB2_query_directory SMB2_query_directory_init cifs_send_recv smb2_parse_query_directory srch_inf->ntwrk_buf_start = (char *)rsp; srch_inf->srch_entries_start = (char *)rsp + ... srch_inf->last_entry = (char *)rsp + ... srch_inf->smallBuf = true; find_cifs_entry /* if (cfile->srch_inf.ntwrk_buf_start) */ cifs_small_buf_release(cfile->srch_inf // free cifs_readdir ->iterate_shared() /* file->private_data != NULL */ find_cifs_entry /* in while (...) loop */ smb2_query_dir_next ->query_dir_next() SMB2_query_directory SMB2_query_directory_init cifs_send_recv compound_send_recv smb_send_rqst __smb_send_rqst rc = -ERESTARTSYS; /* if (fatal_signal_pending()) */ goto out; return rc /* if (cfile->srch_inf.last_entry) */ cifs_save_resume_key() cifs_fill_dirent // UAF /* if (rc) */ return -ENOENT; Fix this by ensuring the return code is checked before using pointers from the srch_inf. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220131 [1] Fixes: a364bc0b37f1 ("[CIFS] fix saving of resume key before CIFSFindNext") Cc: stable(a)vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c index 50f96259d9ad..67d7dd64b5e2 100644 --- a/fs/smb/client/readdir.c +++ b/fs/smb/client/readdir.c @@ -756,11 +756,11 @@ find_cifs_entry(const unsigned int xid, struct cifs_tcon *tcon, loff_t pos, rc = server->ops->query_dir_next(xid, tcon, &cfile->fid, search_flags, &cfile->srch_inf); + if (rc) + return -ENOENT; /* FindFirst/Next set last_entry to NULL on malformed reply */ if (cfile->srch_inf.last_entry) cifs_save_resume_key(cfile->srch_inf.last_entry, cfile); - if (rc) - return -ENOENT; } if (index_to_find < cfile->srch_inf.index_of_last_entry) { /* we found the buffer that contains the entry */

1 month

2
2
0 0

FAILED: patch "[PATCH] smb: client: Fix use-after-free in cifs_fill_dirent" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x a7a8fe56e932a36f43e031b398aef92341bf5ea0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052435-guts-tinfoil-42a7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a7a8fe56e932a36f43e031b398aef92341bf5ea0 Mon Sep 17 00:00:00 2001 From: Wang Zhaolong <wangzhaolong1(a)huawei.com> Date: Fri, 16 May 2025 17:12:55 +0800 Subject: [PATCH] smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK> Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------------------------------------- cifs_readdir /* file->private_data == NULL */ initiate_cifs_search cifsFile = kzalloc(sizeof(struct cifsFileInfo), GFP_KERNEL); smb2_query_dir_first ->query_dir_first() SMB2_query_directory SMB2_query_directory_init cifs_send_recv smb2_parse_query_directory srch_inf->ntwrk_buf_start = (char *)rsp; srch_inf->srch_entries_start = (char *)rsp + ... srch_inf->last_entry = (char *)rsp + ... srch_inf->smallBuf = true; find_cifs_entry /* if (cfile->srch_inf.ntwrk_buf_start) */ cifs_small_buf_release(cfile->srch_inf // free cifs_readdir ->iterate_shared() /* file->private_data != NULL */ find_cifs_entry /* in while (...) loop */ smb2_query_dir_next ->query_dir_next() SMB2_query_directory SMB2_query_directory_init cifs_send_recv compound_send_recv smb_send_rqst __smb_send_rqst rc = -ERESTARTSYS; /* if (fatal_signal_pending()) */ goto out; return rc /* if (cfile->srch_inf.last_entry) */ cifs_save_resume_key() cifs_fill_dirent // UAF /* if (rc) */ return -ENOENT; Fix this by ensuring the return code is checked before using pointers from the srch_inf. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220131 [1] Fixes: a364bc0b37f1 ("[CIFS] fix saving of resume key before CIFSFindNext") Cc: stable(a)vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c index 50f96259d9ad..67d7dd64b5e2 100644 --- a/fs/smb/client/readdir.c +++ b/fs/smb/client/readdir.c @@ -756,11 +756,11 @@ find_cifs_entry(const unsigned int xid, struct cifs_tcon *tcon, loff_t pos, rc = server->ops->query_dir_next(xid, tcon, &cfile->fid, search_flags, &cfile->srch_inf); + if (rc) + return -ENOENT; /* FindFirst/Next set last_entry to NULL on malformed reply */ if (cfile->srch_inf.last_entry) cifs_save_resume_key(cfile->srch_inf.last_entry, cfile); - if (rc) - return -ENOENT; } if (index_to_find < cfile->srch_inf.index_of_last_entry) { /* we found the buffer that contains the entry */

1 month

2
2
0 0

FAILED: patch "[PATCH] smb: client: Fix use-after-free in cifs_fill_dirent" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x a7a8fe56e932a36f43e031b398aef92341bf5ea0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052432-deafening-parted-13e0@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a7a8fe56e932a36f43e031b398aef92341bf5ea0 Mon Sep 17 00:00:00 2001 From: Wang Zhaolong <wangzhaolong1(a)huawei.com> Date: Fri, 16 May 2025 17:12:55 +0800 Subject: [PATCH] smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK> Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------------------------------------- cifs_readdir /* file->private_data == NULL */ initiate_cifs_search cifsFile = kzalloc(sizeof(struct cifsFileInfo), GFP_KERNEL); smb2_query_dir_first ->query_dir_first() SMB2_query_directory SMB2_query_directory_init cifs_send_recv smb2_parse_query_directory srch_inf->ntwrk_buf_start = (char *)rsp; srch_inf->srch_entries_start = (char *)rsp + ... srch_inf->last_entry = (char *)rsp + ... srch_inf->smallBuf = true; find_cifs_entry /* if (cfile->srch_inf.ntwrk_buf_start) */ cifs_small_buf_release(cfile->srch_inf // free cifs_readdir ->iterate_shared() /* file->private_data != NULL */ find_cifs_entry /* in while (...) loop */ smb2_query_dir_next ->query_dir_next() SMB2_query_directory SMB2_query_directory_init cifs_send_recv compound_send_recv smb_send_rqst __smb_send_rqst rc = -ERESTARTSYS; /* if (fatal_signal_pending()) */ goto out; return rc /* if (cfile->srch_inf.last_entry) */ cifs_save_resume_key() cifs_fill_dirent // UAF /* if (rc) */ return -ENOENT; Fix this by ensuring the return code is checked before using pointers from the srch_inf. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220131 [1] Fixes: a364bc0b37f1 ("[CIFS] fix saving of resume key before CIFSFindNext") Cc: stable(a)vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c index 50f96259d9ad..67d7dd64b5e2 100644 --- a/fs/smb/client/readdir.c +++ b/fs/smb/client/readdir.c @@ -756,11 +756,11 @@ find_cifs_entry(const unsigned int xid, struct cifs_tcon *tcon, loff_t pos, rc = server->ops->query_dir_next(xid, tcon, &cfile->fid, search_flags, &cfile->srch_inf); + if (rc) + return -ENOENT; /* FindFirst/Next set last_entry to NULL on malformed reply */ if (cfile->srch_inf.last_entry) cifs_save_resume_key(cfile->srch_inf.last_entry, cfile); - if (rc) - return -ENOENT; } if (index_to_find < cfile->srch_inf.index_of_last_entry) { /* we found the buffer that contains the entry */

1 month

2
4
0 0

6.12.30: black screen after waking up from hibernate; bisected

by Rainer Fiebig

With kernel 6.12.30 waking up from hibernate fails in a Ryzen 3 5600G system with the latest BIOS. At the end of the wake-up procedure the screen goes black instead of showing the log-in screen and the system becomes unresponsive. A hard reset is necessary. Seeing messages like the following in the system log, I suspected an amdgpu problem: May 23 19:09:30 LUX kernel: [16885.524496] amdgpu 0000:30:00.0: [drm] *ERROR* flip_done timed out May 23 19:09:30 LUX kernel: [16885.524501] amdgpu 0000:30:00.0: [drm] *ERROR* [CRTC:73:crtc-0] commit wait timed out I don't know whether those messages and the problem are really related but I bisected in 'drivers/gpu/drm/amd' anyway and the result was: > git bisect bad 25e07c8403f4daad35cffc18d96e32a80a2a3222 is the first bad commit commit 25e07c8403f4daad35cffc18d96e32a80a2a3222 (HEAD) Author: Alex Deucher <alexander.deucher(a)amd.com> Date: Thu May 1 13:46:46 2025 -0400 drm/amdgpu: fix pm notifier handling commit 4aaffc85751da5722e858e4333e8cf0aa4b6c78f upstream. Set the s3/s0ix and s4 flags in the pm notifier so that we can skip the resource evictions properly in pm prepare based on whether we are suspending or hibernating. Drop the eviction as processes are not frozen at this time, we we can end up getting stuck trying to evict VRAM while applications continue to submit work which causes the buffers to get pulled back into VRAM. HTH. Thanks. Rainer -- The truth always turns out to be simpler than you thought. Richard Feynman

1 month

3
5
0 0

[PATCH] rtc: pcf2127: add missing semicolon after statement

by Hugo Villeneuve

From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Replace comma with semicolon at the end of the statement when setting config.max_register. Fixes: fd28ceb4603f ("rtc: pcf2127: add variant-specific configuration structure") Cc: stable(a)vger.kernel.org Cc: Elena Popa <elena.popa(a)nxp.com> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> --- drivers/rtc/rtc-pcf2127.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c index 31c7dca8f469..2bfebe3eba0c 100644 --- a/drivers/rtc/rtc-pcf2127.c +++ b/drivers/rtc/rtc-pcf2127.c @@ -1538,7 +1538,7 @@ static int pcf2127_spi_probe(struct spi_device *spi) variant = &pcf21xx_cfg[type]; } - config.max_register = variant->max_register, + config.max_register = variant->max_register; regmap = devm_regmap_init_spi(spi, &config); if (IS_ERR(regmap)) { base-commit: c7622a4e44d9d008e0e5edcc46c71854c50cf4a8 -- 2.39.5

1 month

1
0
0 0

+ mm-fix-uprobe-pte-be-overwritten-when-expanding-vma.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix uprobe pte be overwritten when expanding vma has been added to the -mm mm-unstable branch. Its filename is mm-fix-uprobe-pte-be-overwritten-when-expanding-vma.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-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: Pu Lehui <pulehui(a)huawei.com> Subject: mm: fix uprobe pte be overwritten when expanding vma Date: Thu, 29 May 2025 15:56:47 +0000 Patch series "Fix uprobe pte be overwritten when expanding vma". This patch (of 4): We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/ Link: https://lkml.kernel.org/r/20250529155650.4017699-1-pulehui@huaweicloud.com Link: https://lkml.kernel.org/r/20250529155650.4017699-2-pulehui@huaweicloud.com Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Signed-off-by: Pu Lehui <pulehui(a)huawei.com> Suggested-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vma.c | 20 +++++++++++++++++--- mm/vma.h | 7 +++++++ 2 files changed, 24 insertions(+), 3 deletions(-) --- a/mm/vma.c~mm-fix-uprobe-pte-be-overwritten-when-expanding-vma +++ a/mm/vma.c @@ -169,6 +169,9 @@ static void init_multi_vma_prep(struct v vp->file = vma->vm_file; if (vp->file) vp->mapping = vma->vm_file->f_mapping; + + if (vmg && vmg->skip_vma_uprobe) + vp->skip_vma_uprobe = true; } /* @@ -358,10 +361,13 @@ static void vma_complete(struct vma_prep if (vp->file) { i_mmap_unlock_write(vp->mapping); - uprobe_mmap(vp->vma); - if (vp->adj_next) - uprobe_mmap(vp->adj_next); + if (!vp->skip_vma_uprobe) { + uprobe_mmap(vp->vma); + + if (vp->adj_next) + uprobe_mmap(vp->adj_next); + } } if (vp->remove) { @@ -1830,6 +1836,14 @@ struct vm_area_struct *copy_vma(struct v faulted_in_anon_vma = false; } + /* + * If the VMA we are copying might contain a uprobe PTE, ensure + * that we do not establish one upon merge. Otherwise, when mremap() + * moves page tables, it will orphan the newly created PTE. + */ + if (vma->vm_file) + vmg.skip_vma_uprobe = true; + new_vma = find_vma_prev(mm, addr, &vmg.prev); if (new_vma && new_vma->vm_start < addr + len) return NULL; /* should never get here */ --- a/mm/vma.h~mm-fix-uprobe-pte-be-overwritten-when-expanding-vma +++ a/mm/vma.h @@ -19,6 +19,8 @@ struct vma_prepare { struct vm_area_struct *insert; struct vm_area_struct *remove; struct vm_area_struct *remove2; + + bool skip_vma_uprobe :1; }; struct unlink_vma_file_batch { @@ -120,6 +122,11 @@ struct vma_merge_struct { */ bool give_up_on_oom :1; + /* + * If set, skip uprobe_mmap upon merged vma. + */ + bool skip_vma_uprobe :1; + /* Internal flags set during merge process: */ /* _ Patches currently in -mm which might be from pulehui(a)huawei.com are mm-fix-uprobe-pte-be-overwritten-when-expanding-vma.patch mm-expose-abnormal-new_pte-during-move_ptes.patch selftests-mm-extract-read_sysfs-and-write_sysfs-into-vm_util.patch selftests-mm-add-test-about-uprobe-pte-be-orphan-during-vma-merge.patch

1 month

1
0
0 0

[PATCH] x86/mm: Fix paging-structure cache flush on kernel table freeing

by Jann Horn

There are several issues in pud_free_pmd_page() and pmd_free_pte_page(), which are used by vmalloc: 1. flush_tlb_kernel_range() does not flush paging-structure caches for inactive PCIDs, but we're using it when freeing kernel page tables. 2. flush_tlb_kernel_range() only flushes paging-structure cache entries that intersect with the flush range, and pud_free_pmd_page() passes in the first PAGE_SIZE bytes of the area covered by the PMD table; but pud_free_pmd_page() is actually designed to also remove PTE tables that were installed in the PMD table, so we need to also flush those. 3. [theoretical issue] invlpgb_kernel_range_flush() expects an exclusive range, it does: `nr = (info->end - addr) >> PAGE_SHIFT;` But pmd_free_pte_page() and pud_free_pmd_page() provide inclusive ranges (`addr, addr + PAGE_SIZE-1`). To fix it: 1. Add a new helper flush_tlb_kernel_pgtable_range() for flushing paging structure caches for kernel page tables, and use that. 2. Flush PUD_SIZE instead of PAGE_SIZE in pud_free_pmd_page(). 3. Remove `-1` in end address calculations. Note that since I'm not touching invlpgb_kernel_range_flush() or invlpgb_flush_addr_nosync() in this patch, the flush on PMD table deletion with INVLPGB might be a bit slow due to using PTE_STRIDE instead of PMD_STRIDE. I don't think that matters. Backport notes: Kernels before 6.16 don't have invlpgb_kernel_range_flush(); for them, kernel_tlb_flush_pgtable() should just unconditionally call flush_tlb_all(). I am marking this as fixing commit 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces"); that is technically incorrect, since back then no paging-structure cache invalidations were performed at all, but probably makes the most sense here. Cc: stable(a)vger.kernel.org Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Jann Horn <jannh(a)google.com> --- arch/x86/include/asm/tlb.h | 4 ++++ arch/x86/include/asm/tlbflush.h | 1 + arch/x86/mm/pgtable.c | 13 +++++++++---- arch/x86/mm/tlb.c | 37 +++++++++++++++++++++++++++++++++++++ 4 files changed, 51 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h index 866ea78ba156..56a4b93a0742 100644 --- a/arch/x86/include/asm/tlb.h +++ b/arch/x86/include/asm/tlb.h @@ -153,6 +153,10 @@ static inline void invlpgb_flush_all(void) /* Flush addr, including globals, for all PCIDs. */ static inline void invlpgb_flush_addr_nosync(unsigned long addr, u16 nr) { + /* + * Don't set INVLPGB_FLAG_FINAL_ONLY here without adjusting + * kernel_tlb_flush_pgtable(). + */ __invlpgb(0, 0, addr, nr, PTE_STRIDE, INVLPGB_FLAG_INCLUDE_GLOBAL); } diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index e9b81876ebe4..06a4a2b7a9f5 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -318,6 +318,7 @@ extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, unsigned long end, unsigned int stride_shift, bool freed_tables); extern void flush_tlb_kernel_range(unsigned long start, unsigned long end); +void flush_tlb_kernel_pgtable_range(unsigned long start, unsigned long end); static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a) { diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 62777ba4de1a..0779ed02226c 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -745,8 +745,13 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr) pud_clear(pud); - /* INVLPG to clear all paging-structure caches */ - flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1); + /* + * Clear paging-structure caches. + * Note that since this function can remove a PMD table together with the + * PTE tables it points to, we can't just flush the first PAGE_SIZE, we + * must flush PUD_SIZE! + */ + flush_tlb_kernel_pgtable_range(addr, addr + PUD_SIZE); for (i = 0; i < PTRS_PER_PMD; i++) { if (!pmd_none(pmd_sv[i])) { @@ -778,8 +783,8 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) pte = (pte_t *)pmd_page_vaddr(*pmd); pmd_clear(pmd); - /* INVLPG to clear all paging-structure caches */ - flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1); + /* clear paging-structure caches */ + flush_tlb_kernel_pgtable_range(addr, addr + PAGE_SIZE); free_page((unsigned long)pte); diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 39f80111e6f1..26b78451a7ed 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -1525,6 +1525,22 @@ static void kernel_tlb_flush_range(struct flush_tlb_info *info) on_each_cpu(do_kernel_range_flush, info, 1); } +static void kernel_tlb_flush_pgtable(struct flush_tlb_info *info) +{ + /* + * The special thing about removing kernel page tables is that we can't + * use a flush that just removes global TLB entries; we need one that + * flushes paging structure caches across all PCIDs. + * With INVLPGB, that's explicitly supported. + * Otherwise, there's no good way (INVLPG and INVPCID can't specifically + * target one address across all PCIDs), just throw everything away. + */ + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) + invlpgb_kernel_range_flush(info); + else + flush_tlb_all(); +} + void flush_tlb_kernel_range(unsigned long start, unsigned long end) { struct flush_tlb_info *info; @@ -1542,6 +1558,27 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end) put_flush_tlb_info(); } +/* + * Flush paging-structure cache entries for page tables covering the specified + * range and synchronize with concurrent hardware page table walks, in + * preparation for freeing page tables in the region. + * This must not be used for flushing translations to data pages. + */ +void flush_tlb_kernel_pgtable_range(unsigned long start, unsigned long end) +{ + struct flush_tlb_info *info; + + /* We don't synchronize against GUP-fast. */ + VM_WARN_ON(start < TASK_SIZE_MAX); + + guard(preempt)(); + + info = get_flush_tlb_info(NULL, start, end, PMD_SHIFT, true, + TLB_GENERATION_INVALID); + kernel_tlb_flush_pgtable(info); + put_flush_tlb_info(); +} + /* * This can be used from process context to figure out what the value of * CR3 is without needing to do a (slow) __read_cr3(). --- base-commit: b1456f6dc167f7f101746e495bede2bac3d0e19f change-id: 20250528-x86-fix-vmap-pt-del-flush-f9fa4f287c93 -- Jann Horn <jannh(a)google.com>

1 month

2
1
0 0

[PATCH v6.6 00/26] af_unix: Align with upstream to avoid a potential UAF

by Lee Jones

From: Lee Jones <joneslee(a)google.com> This is the second attempt at achieving the same goal. This time, the submission avoids forking the current code base, ensuring it remains easier to maintain over time. The set has been tested using the SCM_RIGHTS test suite [1] using QEMU and has been seen to successfully mitigate a UAF on on a top tier handset. RESULTS: TAP version 13 1..20 # Starting 20 tests from 5 test cases. # RUN scm_rights.dgram.self_ref ... # OK scm_rights.dgram.self_ref ok 1 scm_rights.dgram.self_ref # RUN scm_rights.dgram.triangle ... # OK scm_rights.dgram.triangle ok 2 scm_rights.dgram.triangle # RUN scm_rights.dgram.cross_edge ... # OK scm_rights.dgram.cross_edge ok 3 scm_rights.dgram.cross_edge # RUN scm_rights.dgram.backtrack_from_scc ... # OK scm_rights.dgram.backtrack_from_scc ok 4 scm_rights.dgram.backtrack_from_scc # RUN scm_rights.stream.self_ref ... # OK scm_rights.stream.self_ref ok 5 scm_rights.stream.self_ref # RUN scm_rights.stream.triangle ... # OK scm_rights.stream.triangle ok 6 scm_rights.stream.triangle # RUN scm_rights.stream.cross_edge ... # OK scm_rights.stream.cross_edge ok 7 scm_rights.stream.cross_edge # RUN scm_rights.stream.backtrack_from_scc ... # OK scm_rights.stream.backtrack_from_scc ok 8 scm_rights.stream.backtrack_from_scc # RUN scm_rights.stream_oob.self_ref ... # OK scm_rights.stream_oob.self_ref ok 9 scm_rights.stream_oob.self_ref # RUN scm_rights.stream_oob.triangle ... # OK scm_rights.stream_oob.triangle ok 10 scm_rights.stream_oob.triangle # RUN scm_rights.stream_oob.cross_edge ... # OK scm_rights.stream_oob.cross_edge ok 11 scm_rights.stream_oob.cross_edge # RUN scm_rights.stream_oob.backtrack_from_scc ... # OK scm_rights.stream_oob.backtrack_from_scc ok 12 scm_rights.stream_oob.backtrack_from_scc # RUN scm_rights.stream_listener.self_ref ... # OK scm_rights.stream_listener.self_ref ok 13 scm_rights.stream_listener.self_ref # RUN scm_rights.stream_listener.triangle ... # OK scm_rights.stream_listener.triangle ok 14 scm_rights.stream_listener.triangle # RUN scm_rights.stream_listener.cross_edge ... # OK scm_rights.stream_listener.cross_edge ok 15 scm_rights.stream_listener.cross_edge # RUN scm_rights.stream_listener.backtrack_from_scc ... # OK scm_rights.stream_listener.backtrack_from_scc ok 16 scm_rights.stream_listener.backtrack_from_scc # RUN scm_rights.stream_listener_oob.self_ref ... # OK scm_rights.stream_listener_oob.self_ref ok 17 scm_rights.stream_listener_oob.self_ref # RUN scm_rights.stream_listener_oob.triangle ... # OK scm_rights.stream_listener_oob.triangle ok 18 scm_rights.stream_listener_oob.triangle # RUN scm_rights.stream_listener_oob.cross_edge ... # OK scm_rights.stream_listener_oob.cross_edge ok 19 scm_rights.stream_listener_oob.cross_edge # RUN scm_rights.stream_listener_oob.backtrack_from_scc ... # OK scm_rights.stream_listener_oob.backtrack_from_scc ok 20 scm_rights.stream_listener_oob.backtrack_from_scc # PASSED: 20 / 20 tests passed. # Totals: pass:20 fail:0 xfail:0 xpass:0 skip:0 error:0 [0] https://lore.kernel.org/all/20250304030149.82265-1-kuniyu@amazon.com/ [1] https://lore.kernel.org/all/20240325202425.60930-16-kuniyu@amazon.com/ Kuniyuki Iwashima (24): af_unix: Return struct unix_sock from unix_get_socket(). af_unix: Run GC on only one CPU. af_unix: Try to run GC async. af_unix: Replace BUG_ON() with WARN_ON_ONCE(). af_unix: Remove io_uring code for GC. af_unix: Remove CONFIG_UNIX_SCM. af_unix: Allocate struct unix_vertex for each inflight AF_UNIX fd. af_unix: Allocate struct unix_edge for each inflight AF_UNIX fd. af_unix: Link struct unix_edge when queuing skb. af_unix: Bulk update unix_tot_inflight/unix_inflight when queuing skb. af_unix: Iterate all vertices by DFS. af_unix: Detect Strongly Connected Components. af_unix: Save listener for embryo socket. af_unix: Fix up unix_edge.successor for embryo socket. af_unix: Save O(n) setup of Tarjan's algo. af_unix: Skip GC if no cycle exists. af_unix: Avoid Tarjan's algorithm if unnecessary. af_unix: Assign a unique index to SCC. af_unix: Detect dead SCC. af_unix: Replace garbage collection algorithm. af_unix: Remove lock dance in unix_peek_fds(). af_unix: Try not to hold unix_gc_lock during accept(). af_unix: Don't access successor in unix_del_edges() during GC. af_unix: Add dead flag to struct scm_fp_list. Michal Luczaj (1): af_unix: Fix garbage collection of embryos carrying OOB with SCM_RIGHTS Shigeru Yoshida (1): af_unix: Fix uninit-value in __unix_walk_scc() include/net/af_unix.h | 49 ++- include/net/scm.h | 11 + net/Makefile | 2 +- net/core/scm.c | 17 ++ net/unix/Kconfig | 5 - net/unix/Makefile | 2 - net/unix/af_unix.c | 120 +++++--- net/unix/garbage.c | 691 +++++++++++++++++++++++++++++------------- net/unix/scm.c | 161 ---------- net/unix/scm.h | 10 - 10 files changed, 617 insertions(+), 451 deletions(-) delete mode 100644 net/unix/scm.c delete mode 100644 net/unix/scm.h -- 2.49.0.1112.g889b7c5bd8-goog

1 month

3
53
0 0

Backports of 2e43ae7dd71cd9bb0d1bce1d3306bf77523feb81 for 5.15 and older

by Nathan Chancellor

Hi Greg and Sasha, Please find attached backports of commit 2e43ae7dd71c ("drm/i915/gvt: fix unterminated-string-initialization warning") to address an instance of -Wunterminated-string-initialization that appears in the i915 driver with GCC 15 and Clang 21 due to its use of -Wextra. Please let me know if there are any issues. Cheers, Nathan

1 month

2
1
0 0

[PATCH 6.1.y] selftests/vm: fix split huge page tests

by wndgwang4

From: Zi Yan <ziy(a)nvidia.com> [ upstream commit dd63bd7df41a8f9393a2e3ff9157a441c08eb996 ] Fix two inputs to check_anon_huge() and one if condition, so the tests work as expected. Steps to reproduce the issue. make headers make -C tools/testing/selftests/vm Before patching:test fails with a non-zero exit code ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test | echo 0 2 ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test No THP is allocated After patching: ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test | echo 0 0 ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test Split huge pages successful ... Link: https://lkml.kernel.org/r/20230306160907.16804-1-zi.yan@sent.com Fixes: c07c343cda8e ("selftests/vm: dedup THP helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Zach O'Keefe <zokeefe(a)google.com> Tested-by: Zach O'Keefe <zokeefe(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: wndgwang4 <guangming.wang(a)windriver.com> --- tools/testing/selftests/vm/split_huge_page_test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/vm/split_huge_page_test.c b/tools/testing/selftests/vm/split_huge_page_test.c index 76e1c36dd..b8558c7f1 100644 --- a/tools/testing/selftests/vm/split_huge_page_test.c +++ b/tools/testing/selftests/vm/split_huge_page_test.c @@ -106,7 +106,7 @@ void split_pmd_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } @@ -122,7 +122,7 @@ void split_pmd_thp(void) } - if (check_huge_anon(one_page, 0, pmd_pagesize)) { + if (!check_huge_anon(one_page, 0, pmd_pagesize)) { printf("Still AnonHugePages not split\n"); exit(EXIT_FAILURE); } @@ -169,7 +169,7 @@ void split_pte_mapped_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } -- 2.34.1

1 month

2
1
0 0

[PATCH net] can: kvaser_pciefd: refine error prone echo_skb_max handling logic

by Marc Kleine-Budde

From: Fedor Pchelkin <pchelkin(a)ispras.ru> echo_skb_max should define the supported upper limit of echo_skb[] allocated inside the netdevice's priv. The corresponding size value provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT which is 17. But later echo_skb_max is rounded up to the nearest power of two (for the max case, that would be 32) and the tx/ack indices calculated further during tx/rx may exceed the upper array boundary. Kasan reported this for the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit function has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: <IRQ> dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 </IRQ> Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq numbers' generation that's not the case - we're free to calculate them as would be more convenient, not taking tx max count into account. The only downside is that the size of echo_skb[] should correspond to the max seq number (not tx max count), so in some situations a bit more memory would be consumed than could be. Thus make the size of the underlying echo_skb[] sufficient for the rounded max tx value. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 8256e0ca6010 ("can: kvaser_pciefd: Fix echo_skb race") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Link: https://patch.msgid.link/20250528192713.63894-1-pchelkin@ispras.ru Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/kvaser_pciefd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c index 7d3066691d5d..52301511ed1b 100644 --- a/drivers/net/can/kvaser_pciefd.c +++ b/drivers/net/can/kvaser_pciefd.c @@ -966,7 +966,7 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie) u32 status, tx_nr_packets_max; netdev = alloc_candev(sizeof(struct kvaser_pciefd_can), - KVASER_PCIEFD_CAN_TX_MAX_COUNT); + roundup_pow_of_two(KVASER_PCIEFD_CAN_TX_MAX_COUNT)); if (!netdev) return -ENOMEM; @@ -995,7 +995,6 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie) can->tx_max_count = min(KVASER_PCIEFD_CAN_TX_MAX_COUNT, tx_nr_packets_max - 1); can->can.clock.freq = pcie->freq; - can->can.echo_skb_max = roundup_pow_of_two(can->tx_max_count); spin_lock_init(&can->lock); can->can.bittiming_const = &kvaser_pciefd_bittiming_const; base-commit: 271683bb2cf32e5126c592b5d5e6a756fa374fd9 -- 2.47.2

1 month

2
1
0 0

[PATCH] driver: net: ethernet: mtk_star_emac: fix suspend/resume issue

by Macpaul Lin

From: Yanqing Wang <ot_yanqing.wang(a)mediatek.com> Identify the cause of the suspend/resume hang: netif_carrier_off() is called during link state changes and becomes stuck while executing linkwatch_work(). To resolve this issue, call netif_device_detach() during the Ethernet suspend process to temporarily detach the network device from the kernel and prevent the suspend/resume hang. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Yanqing Wang <ot_yanqing.wang(a)mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com> Signed-off-by: Biao Huang <biao.huang(a)mediatek.com> --- drivers/net/ethernet/mediatek/mtk_star_emac.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c index b175119a6a7d..b83886a41121 100644 --- a/drivers/net/ethernet/mediatek/mtk_star_emac.c +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c @@ -1463,6 +1463,8 @@ static __maybe_unused int mtk_star_suspend(struct device *dev) if (netif_running(ndev)) mtk_star_disable(ndev); + netif_device_detach(ndev); + clk_bulk_disable_unprepare(MTK_STAR_NCLKS, priv->clks); return 0; @@ -1487,6 +1489,8 @@ static __maybe_unused int mtk_star_resume(struct device *dev) clk_bulk_disable_unprepare(MTK_STAR_NCLKS, priv->clks); } + netif_device_attach(ndev); + return ret; } -- 2.45.2

1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025