[core] Fix ESP32-S2/S3 hardware SHA crash by aligning HashBase digest buffer

Co-authored-by: Clyde Stubbs <2366188+clydebarrow@users.noreply.github.com>

esphome/components/esp32_hosted/update/esp32_hosted_update.cpp

@@ -294,8 +294,7 @@ bool Esp32HostedUpdate::stream_firmware_to_coprocessor_() {
   }
 
   // Stream firmware to coprocessor while computing SHA256
-  // Hardware SHA acceleration requires 32-byte alignment on some chips (ESP32-S3 with IDF 5.5.x+)
-  alignas(32) sha256::SHA256 hasher;
+  sha256::SHA256 hasher;
   hasher.init();
 
   uint8_t buffer[CHUNK_SIZE];
@@ -352,8 +351,7 @@ bool Esp32HostedUpdate::write_embedded_firmware_to_coprocessor_() {
   }
 
   // Verify SHA256 before writing
-  // Hardware SHA acceleration requires 32-byte alignment on some chips (ESP32-S3 with IDF 5.5.x+)
-  alignas(32) sha256::SHA256 hasher;
+  sha256::SHA256 hasher;
   hasher.init();
   hasher.add(this->firmware_data_, this->firmware_size_);
   hasher.calculate();

esphome/components/esphome/ota/ota_esphome.cpp

@@ -563,11 +563,9 @@ bool ESPHomeOTAComponent::handle_auth_send_() {
     //   [1+hex_size...1+2*hex_size-1]: cnonce (hex_size bytes) - client's nonce
     //   [1+2*hex_size...1+3*hex_size-1]: response (hex_size bytes) - client's hash
 
-    // CRITICAL ESP32-S3 HARDWARE SHA ACCELERATION: Hash object must stay in same stack frame
+    // CRITICAL ESP32-S2/S3 HARDWARE SHA ACCELERATION: Hash object must stay in same stack frame
     // (no passing to other functions). All hash operations must happen in this function.
-    // NOTE: On ESP32-S3 with IDF 5.5.x, the SHA256 context must be properly aligned for
-    // hardware SHA acceleration DMA operations.
-    alignas(32) sha256::SHA256 hasher;
+    sha256::SHA256 hasher;
 
     const size_t hex_size = hasher.get_size() * 2;
     const size_t nonce_len = hasher.get_size() / 4;
@@ -639,11 +637,9 @@ bool ESPHomeOTAComponent::handle_auth_read_() {
   const char *cnonce = nonce + hex_size;
   const char *response = cnonce + hex_size;
 
-  // CRITICAL ESP32-S3 HARDWARE SHA ACCELERATION: Hash object must stay in same stack frame
+  // CRITICAL ESP32-S2/S3 HARDWARE SHA ACCELERATION: Hash object must stay in same stack frame
   // (no passing to other functions). All hash operations must happen in this function.
-  // NOTE: On ESP32-S3 with IDF 5.5.x, the SHA256 context must be properly aligned for
-  // hardware SHA acceleration DMA operations.
-  alignas(32) sha256::SHA256 hasher;
+  sha256::SHA256 hasher;
 
   hasher.init();
   hasher.add(this->password_.c_str(), this->password_.length());

esphome/components/image/__init__.py

@@ -665,15 +665,10 @@ async def write_image(config, all_frames=False):
         if is_svg_file(path):
             import resvg_py
 
-            if resize:
-                width, height = resize
-                # resvg-py allows rendering by width/height directly
-                image_data = resvg_py.svg_to_bytes(
-                    svg_path=str(path), width=int(width), height=int(height)
-                )
-            else:
-                # Default size
-                image_data = resvg_py.svg_to_bytes(svg_path=str(path))
+            resize = resize or (None, None)
+            image_data = resvg_py.svg_to_bytes(
+                svg_path=str(path), width=resize[0], height=resize[1], dpi=100
+            )
 
             # Convert bytes to Pillow Image
             image = Image.open(io.BytesIO(image_data))

esphome/components/lvgl/lv_validation.py

@@ -413,6 +413,7 @@ class TextValidator(LValidator):
                 str_args = [str(x) for x in value[CONF_ARGS]]
                 arg_expr = cg.RawExpression(",".join(str_args))
                 format_str = cpp_string_escape(format_str)
+                # str_sprintf justified: user-defined format, can't optimize without permanent RAM cost
                 sprintf_str = f"str_sprintf({format_str}, {arg_expr}).c_str()"
                 if nanval := value.get(CONF_IF_NAN):
                     nanval = cpp_string_escape(nanval)

esphome/components/lvgl/lvgl_esphome.cpp

@@ -65,7 +65,10 @@ std::string lv_event_code_name_for(uint8_t event_code) {
   if (event_code < sizeof(EVENT_NAMES) / sizeof(EVENT_NAMES[0])) {
     return EVENT_NAMES[event_code];
   }
-  return str_sprintf("%2d", event_code);
+  // max 4 bytes: "%u" with uint8_t (max 255, 3 digits) + null
+  char buf[4];
+  snprintf(buf, sizeof(buf), "%u", event_code);
+  return buf;
 }
 
 static void rounder_cb(lv_disp_drv_t *disp_drv, lv_area_t *area) {

esphome/components/sha256/sha256.cpp

@@ -10,26 +10,24 @@ namespace esphome::sha256 {
 
 #if defined(USE_ESP32) || defined(USE_LIBRETINY)
 
-// CRITICAL ESP32-S3 HARDWARE SHA ACCELERATION REQUIREMENTS (IDF 5.5.x):
+// CRITICAL ESP32-S2/S3 HARDWARE SHA ACCELERATION REQUIREMENTS (IDF 5.5.x):
 //
-// The ESP32-S3 uses hardware DMA for SHA acceleration. The mbedtls_sha256_context structure contains
-// internal state that the DMA engine references. This imposes three critical constraints:
+// The ESP32-S2/S3 uses hardware DMA for SHA acceleration. The DMA engine requires proper
+// alignment of the digest output buffer. This is handled automatically via HashBase::digest_
+// which has alignas(32). This imposes two critical constraints:
 //
-// 1. ALIGNMENT: The SHA256 object MUST be declared with `alignas(32)` for proper DMA alignment.
-//    Without this, the DMA engine may crash with an abort in sha_hal_read_digest().
-//
-// 2. NO VARIABLE LENGTH ARRAYS (VLAs): VLAs corrupt the stack layout, causing the DMA engine to
+// 1. NO VARIABLE LENGTH ARRAYS (VLAs): VLAs corrupt the stack layout, causing the DMA engine to
 //    write to incorrect memory locations. This results in null pointer dereferences and crashes.
 //    ALWAYS use fixed-size arrays (e.g., char buf[65], not char buf[size+1]).
 //
-// 3. SAME STACK FRAME ONLY: The SHA256 object must be created and used entirely within the same
+// 2. SAME STACK FRAME ONLY: The SHA256 object must be created and used entirely within the same
 //    function. NEVER pass the SHA256 object or HashBase pointer to another function. When the stack
 //    frame changes (function call/return), the DMA references become invalid and will produce
 //    truncated hash output (20 bytes instead of 32) or corrupt memory.
 //
 // CORRECT USAGE:
 //   void my_function() {
-//     alignas(32) sha256::SHA256 hasher;  // Created locally with proper alignment
+//     sha256::SHA256 hasher;
 //     hasher.init();
 //     hasher.add(data, len);  // Any size, no chunking needed
 //     hasher.calculate();
@@ -37,9 +35,9 @@ namespace esphome::sha256 {
 //     // hasher destroyed when function returns
 //   }
 //
-// INCORRECT USAGE (WILL FAIL ON ESP32-S3):
+// INCORRECT USAGE (WILL FAIL ON ESP32-S2/S3):
 //   void my_function() {
-//     sha256::SHA256 hasher;  // WRONG: Missing alignas(32)
+//     sha256::SHA256 hasher;
 //     helper(&hasher);  // WRONG: Passed to different stack frame
 //   }
 //   void helper(HashBase *h) {

esphome/components/sha256/sha256.h

@@ -24,13 +24,14 @@ namespace esphome::sha256 {
 
 /// SHA256 hash implementation.
 ///
-/// CRITICAL for ESP32-S3 with IDF 5.5.x hardware SHA acceleration:
-/// 1. SHA256 objects MUST be declared with `alignas(32)` for proper DMA alignment
-/// 2. The object MUST stay in the same stack frame (no passing to other functions)
-/// 3. NO Variable Length Arrays (VLAs) in the same function
+/// CRITICAL for ESP32-S2/S3 with IDF 5.5.x hardware SHA acceleration:
+/// 1. The object MUST stay in the same stack frame (no passing to other functions)
+/// 2. NO Variable Length Arrays (VLAs) in the same function
+///
+/// Note: Alignment is handled automatically via the HashBase::digest_ member.
 ///
 /// Example usage:
-///   alignas(32) sha256::SHA256 hasher;
+///   sha256::SHA256 hasher;
 ///   hasher.init();
 ///   hasher.add(data, len);
 ///   hasher.calculate();

esphome/core/hash_base.h

@@ -44,7 +44,9 @@ class HashBase {
   virtual size_t get_size() const = 0;
 
  protected:
-  uint8_t digest_[32];  // Storage sized for max(MD5=16, SHA256=32) bytes
+  // 32-byte alignment required for ESP32-S2/S3 hardware SHA DMA operations.
+  // This also sets the class alignment to 32, ensuring derived objects are properly aligned.
+  alignas(32) uint8_t digest_[32];  // Storage sized for max(MD5=16, SHA256=32) bytes
 };
 
 }  // namespace esphome

requirements.txt

@@ -19,7 +19,7 @@ ruamel.yaml==0.19.1 # dashboard_import
 ruamel.yaml.clib==0.2.15 # dashboard_import
 esphome-glyphsets==0.2.0
 pillow==11.3.0
-resvg-py==0.2.5
+resvg-py==0.2.6
 freetype-py==2.5.1
 jinja2==3.1.6
 bleak==2.1.1

tests/component_tests/image/config/mm_dimensions.svg

@@ -0,0 +1,5 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg xmlns="http://www.w3.org/2000/svg" width="10mm" height="10mm" viewBox="0 0 100 100">
+  <rect x="0" y="0" width="100" height="100" fill="#00FF00"/>
+  <circle cx="50" cy="50" r="30" fill="#0000FF"/>
+</svg>

tests/component_tests/image/test_init.py

@@ -5,17 +5,21 @@ from __future__ import annotations
 from collections.abc import Callable
 from pathlib import Path
 from typing import Any
+from unittest.mock import MagicMock, patch
 
 import pytest
 
 from esphome import config_validation as cv
 from esphome.components.image import (
+    CONF_INVERT_ALPHA,
+    CONF_OPAQUE,
     CONF_TRANSPARENCY,
     CONFIG_SCHEMA,
     get_all_image_metadata,
     get_image_metadata,
+    write_image,
 )
-from esphome.const import CONF_ID, CONF_RAW_DATA_ID, CONF_TYPE
+from esphome.const import CONF_DITHER, CONF_FILE, CONF_ID, CONF_RAW_DATA_ID, CONF_TYPE
 from esphome.core import CORE
 
 
@@ -350,3 +354,52 @@ def test_get_all_image_metadata_empty() -> None:
         "get_all_image_metadata should always return a dict"
     )
     # Length could be 0 or more depending on what's in CORE at test time
+
+
+@pytest.fixture
+def mock_progmem_array():
+    """Mock progmem_array to avoid needing a proper ID object in tests."""
+    with patch("esphome.components.image.cg.progmem_array") as mock_progmem:
+        mock_progmem.return_value = MagicMock()
+        yield mock_progmem
+
+
+@pytest.mark.asyncio
+async def test_svg_with_mm_dimensions_succeeds(
+    component_config_path: Callable[[str], Path],
+    mock_progmem_array: MagicMock,
+) -> None:
+    """Test that SVG files with dimensions in mm are successfully processed."""
+    # Create a config for write_image without CONF_RESIZE
+    config = {
+        CONF_FILE: component_config_path("mm_dimensions.svg"),
+        CONF_TYPE: "BINARY",
+        CONF_TRANSPARENCY: CONF_OPAQUE,
+        CONF_DITHER: "NONE",
+        CONF_INVERT_ALPHA: False,
+        CONF_RAW_DATA_ID: "test_raw_data_id",
+    }
+
+    # This should succeed without raising an error
+    result = await write_image(config)
+
+    # Verify that write_image returns the expected tuple
+    assert isinstance(result, tuple), "write_image should return a tuple"
+    assert len(result) == 6, "write_image should return 6 values"
+
+    prog_arr, width, height, image_type, trans_value, frame_count = result
+
+    # Verify the dimensions are positive integers
+    # At 100 DPI, 10mm = ~39 pixels (10mm * 100dpi / 25.4mm_per_inch)
+    assert isinstance(width, int), "Width should be an integer"
+    assert isinstance(height, int), "Height should be an integer"
+    assert width > 0, "Width should be positive"
+    assert height > 0, "Height should be positive"
+    assert frame_count == 1, "Single image should have frame_count of 1"
+    # Verify we got reasonable dimensions from the mm-based SVG
+    assert 30 < width < 50, (
+        f"Width should be around 39 pixels for 10mm at 100dpi, got {width}"
+    )
+    assert 30 < height < 50, (
+        f"Height should be around 39 pixels for 10mm at 100dpi, got {height}"
+    )