Memory corruption or problem with multiline strings in SPI Memory Manager

[nuschpl]

Probably picture will be worth more than hundred words so I'm attaching:

The issue I'm reporting here is not SPI itself related only the GUI part which gets broken in this specific case.
Namely the string Vendor id: 0x20 which should got split into two lines:

• Vendor id:
• 0x20
  Actually get splits into 3 lines:
• Vendor
• i-
• d: 0x20

So I'm betting it somehow related to multiline splitting or just memory corruption.
The code printing it is:

 furi_string_printf(str, "Vendor\nid: 0x%02X", spi_mem_chip_get_vendor_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 16, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));
    furi_string_printf(str, "Type\nid: 0x%02X", spi_mem_chip_get_type_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 64, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));
    furi_string_printf(str, "Capacity\nid: 0x%02X", spi_mem_chip_get_capacity_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 110, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));

I've tried to dig into the code and guessing that this is something related to:
function elements_multiline_text_aligned and its subsequent call to:
size_t chars_fit = elements_get_max_chars_to_fit(canvas, horizontal, start, x); and
line = furi_string_alloc_printf("%.*s-\n", chars_fit, start); where the dash char is added. But I'm unable to quickly determine if this is bug in flipper GUI logic or in the way fapp is using those GUI calls.

[skotopes]

it's not memory corruption, but incorrect text overflow handling

[nuschpl]

Yes, I've realized that in the middle of writing avove with function widget_add_string_multiline_element being good starting candidate. Maybe someone familiar with how this overflow is supposed to work can point to specific logic which might be te cause here.