Dear Maintainer, Here is some additional information that I forgot to mention in the original message:
1. Whether or not the issue happens appears to be semi-random, e.g. it doesn't happen on the x86_64 build, even though the .elf loading code is the same, and the patch I've provided also updates it. It also didn't happen when I enabled global debugging by defining the CORE_DEBUG and DEBUG_STDIO macros on the 32-bit version, I've actually demonstrated that to Philipp Kern on the April 2025 Vienna BSP. 2. Speaking of the April 2025 Vienna BSP, I said there that the issue happened on the prebuilt binaries of syslinux 6.03 from kernel.org too, but that was because of incorrect testing due to the separate issue that causes early error messages in EFI syslinux to be invisible. 3. The issue also doesn't happen on the version of syslinux that's currently in trixie, which appears to have been built back in 2020. 4. The BSS section of an ELF file is not present on-disk, since it's expected to be initialized to zero by the ELF loader. 5. The elf loader in syslinux doesn't currently appear to be able to handle zero-sized sections even if the integer underflow error isn't triggered, it uses image_read() from com32/lib/sys/module/common.c which requires at least one byte to be loaded to report success. 6. In cases when the error doesn't manifest, the loop that goes through the sections doesn't appear to come across an on-disk zero-sized section with p_type == PT_LOAD. I presume there's some sort of section merging process going on, since objdump reports 17 sections to me, but the loop in load_segments() at line 112 of com32/lib/sys/module/i386/elf_module.c appears to only process 4 sections, where only the first 2 are p_type == PT_LOAD, and in the case when the error doesn't occur, there's only one p_type == PT_LOAD section, presumably .bss got merged with the previous sections in that case. Best Regards, Marek
