From: Sebastian Ott sebott@redhat.com
[ Upstream commit 13edf7539211d8f7d0068ce3ed143005f1da3547 ]
Initialization of the local acpi_object in acpi_processor_get_info() only sets the first 4 bytes to zero and is thus incomplete. This is indicated by messages like: acpi ACPI0007:be: Invalid PBLK length [166288104]
Fix this by initializing all 16 bytes of the processor member of that union.
Signed-off-by: Sebastian Ott sebott@redhat.com Link: https://patch.msgid.link/20250703124215.12522-1-sebott@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis, here is my determination:
**Backport Status: YES**
## Extensive Explanation:
This commit fixes a critical initialization bug in the ACPI processor driver that causes incorrect error messages and potentially incorrect behavior. Here's why this is a good candidate for stable backport:
### 1. **Clear Bug Fix** The commit fixes an incomplete initialization issue where `union acpi_object object = { 0 };` only initializes the first 4 bytes (the size of `acpi_object_type type`), leaving the remaining bytes of the union uninitialized. This results in garbage values in fields like `object.processor.pblk_length`, causing spurious error messages like "Invalid PBLK length [166288104]".
### 2. **User-Visible Impact** The bug causes confusing error messages in system logs during ACPI processor initialization. The error message shown in the commit (`acpi ACPI0007:be: Invalid PBLK length [166288104]`) indicates that uninitialized memory is being read and interpreted as a length value.
### 3. **Minimal and Contained Fix** The fix is extremely simple - changing: ```c union acpi_object object = { 0 }; ``` to: ```c union acpi_object object = { .processor = { 0 } }; ```
This ensures proper initialization of all 16 bytes (as mentioned in the commit message) of the processor member of the union, which is 24 bytes in total based on my analysis.
### 4. **No Architectural Changes** This is a pure bug fix with no feature additions or architectural changes. It simply corrects the initialization to prevent reading uninitialized memory.
### 5. **Low Risk of Regression** The change is minimal and only affects initialization. It doesn't alter any logic or behavior beyond ensuring that the union is properly zeroed out. The designated initializer syntax is standard C and well-supported.
### 6. **Critical Subsystem** While ACPI is a critical subsystem, this fix is confined to the initialization of a local variable in `acpi_processor_get_info()`. The scope is limited and the fix is conservative.
### 7. **Follows Stable Rules** This commit perfectly follows the stable kernel rules: - Fixes a real bug (uninitialized memory access) - Small change (single line) - Obviously correct - Already tested (merged into mainline) - Fixes an issue that users see (error messages in logs)
The uninitialized memory access could potentially lead to more serious issues beyond just incorrect error messages, as the code makes decisions based on the `pblk_length` value (checking if it equals 6). This makes the fix even more important for stable kernels.
drivers/acpi/acpi_processor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index c8338d627857..9cbf0593da05 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -228,7 +228,7 @@ static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
static int acpi_processor_get_info(struct acpi_device *device) { - union acpi_object object = { 0 }; + union acpi_object object = { .processor = { 0 } }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; struct acpi_processor *pr = acpi_driver_data(device); int device_declaration = 0;