similar to: [PATCH 0/2] Stack overflows when running commands

From: Sylvain Gault <sylvain.gault at gmail.com> The behavior when running a "CONFIG" command line is to reload ldlinux.c32 with the new file as argument. This call never return. In order to avoid stacking up the calls to start_ldlinux, this patch introduce a setjmp/longjmp to return to the first call to start_ldlinux, thus freeing all the stack space. Signed-off-by: Sylvain

From: Matt Fleming <matt.fleming at intel.com> Here are the patches that I've got queued up based on the very helpful feedback I received from people testing Syslinux 5.00-pre9. Unless anyone has any concerns these will make it into Syslinux 5.00-pre10. Matt Fleming (9): pxe: Don't call open_config() from the pxe core ldlinux: Print a warning if no config file is found

From: Sylvain Gault <sylvain.gault at gmail.com> When a COM32 module exits, the functions never return and a new call to ldlinux_enter_command is made. This could fill the stack and overflow on some data present in memory. This patch use setjmp/longjmp to return to the main function and restart from there when a COM32 module exits. Signed-off-by: Sylvain Gault <sylvain.gault at

On 10/12/15 21:04, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > The behavior when running a "CONFIG" command line is to reload > ldlinux.c32 with the new file as argument. This call never return. > > In order to avoid stacking up the calls to start_ldlinux, this patch > introduce a setjmp/longjmp to return to the

2016-01-09 17:05 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: > On Tue, Oct 13, 2015 at 12:04 AM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> Hello there, >> >> I propose 2 patches that fix two possible stack overflows either when >> running a >> COM32 module

From: Sylvain Gault <sylvain.gault at gmail.com> I found something suspicious while hunting another bug a while ago. The conditions for that bug to occur seems quite hard to meet, but it's still code quality improvement. See the commit message for details. Sylvain Gault (1): efi: Suspicious size reduction in emalloc efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in

From: Sylvain Gault <sylvain.gault at gmail.com> These few patches contain a few improvement about the Makefiles for EFI. Mainly, to rebuild the files when needed, and only when needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh disappeared and are now integrated as makefile recipes. You'll notice an argument ARFLAGS=rvU to the recursive make calls to gnu-efi. This is

From: Sylvain Gault <sylvain.gault at gmail.com> The assembly instruction lgdt take a segment limit that is one less than the actual size, so that base+limit points to the last byte. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/efi/main.c b/efi/main.c index 94878f9..bdf9353 100644

From: Sylvain Gault <sylvain.gault at gmail.com> Missing */ at the end of a comment. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/x86_64/linux.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/x86_64/linux.S b/efi/x86_64/linux.S index 972c0b2..29dde94 100644 --- a/efi/x86_64/linux.S +++ b/efi/x86_64/linux.S @@ -27,7 +27,7 @@ kernel_jump:

From: Sylvain Gault <sylvain.gault at gmail.com> On some architecture, including my hardware, the function ExitBootServices may need to be called twice in order to successfully exit the boot services. As stated by the UEFI spec, the first call to ExitBootServices may perform a partial shutdown of the services. It seems that during this partial shutdown, the memory map can be modified, thus

From: Sylvain Gault <sylvain.gault at gmail.com> The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes above the current stack frame. This area can be used by a called function in order to avoid the overhead of modifying the stack pointer. The direct effect is that interrupt/event/signal handlers must not write to this area. In the UEFI calling convention,

From: Sylvain Gault <sylvain.gault at gmail.com> The command-line parsing used to return a pointer to a local array. The code used to work by chance, but now, gcc 5 is able to detect it and return a NULL pointer instead. The buffer is now marked static. This shouldn't be a problem as only one command line can be read at a time. Signed-off-by: Sylvain Gault <sylvain.gault at

Hello I am working on radio tracking data, with a short programme someone gave me and ... which should, supposedly, work ... In this programme, there is the function : getareahr(kern, levels = 95). But i cannot find any 'getareahr' in R ... could anyone help me? thanks! Agn??s

2014-02-13 4:04 UTC+01:00, Sylvain Gault <sylvain.gault at gmail.com>: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> > > It looks like git-send-email messed the headers when changing the sender. > Actually this was correct. It's the git-send-email way to specify the

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

On Mon, Sep 14, 2015 at 05:50:56AM +0200, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to be rebuilt everytime.

On Mon, 14 Sep 2015 05:50:56 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to

Hello there, When cleaning up the linker scripts I happened to find a bug that was just triggered a lot more easily without the useless sections taking up some memory space. In short, every time you run a COM32 kernel (in the CLI or via a menu) the stack is never restored and the function calls just stack up until you reach other data, which may make anything crash. Here is the backtrace down