[Bug tools/33006] Stack Buffer Overflow in eu-objdump's riscv_disasm Function

2025-06-04 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=33006

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Mark Wielaard  ---
commit 07bd923cea4b883ca2357e9fc80babcedd242b37
Author: Mark Wielaard 
Date:   Tue Jun 3 01:50:07 2025 +0200

libcpu: riscv_disasm use 50 char mnebuf

Some "illegal" instructions can be up to 24 chars (192 bits), We'll
print this as 0x<48 hex chars>. So make sure the mnebuf is 50 chars
(no terminating zero is needed).

This shows up with _FORTIFY_SOURCE which would immediate terminate on
such "illegal" instructions. Without we just use a few extra bytes on
the stack (which aren't used afterwards, without any issue, even
though it is technically UB).

* libcpu/riscv_disasm.c (riscv_disasm): Extend char mnebuf
array to 50.

Signed-off-by: Mark Wielaard 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[COMMITTED] elfutils_debian_amd64_builder use elfutils_factory_mua

2025-06-04 Thread Mark Wielaard
Debian stable only has valgrind 3.19.0 which doesn't have an openat2
syscall wrapper. This makes some elfutils tests fail under valgrind
since it uses openat2 explicitly now. So switch the build factory to
not use valgrind, but the gcc address (and undefined) sanitizer.
---
 builder/master.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builder/master.cfg b/builder/master.cfg
index 8d024f0ac5e7..1c185ca4f5a1 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -2569,7 +2569,7 @@ elfutils_debian_amd64_builder = util.BuilderConfig(
readContainerFile('debian-stable')},
workernames=vm_workers,
 tags=["elfutils", "debian", "x86_64"],
-factory=elfutils_factory_mvu)
+factory=elfutils_factory_mua)
 c['builders'].append(elfutils_debian_amd64_builder)
 
 elfutils_try_debian_amd64_builder = util.BuilderConfig(
-- 
2.49.0



☺ Buildbot (Sourceware): elfutils - build successful (main)

2025-06-04 Thread builder
A restored build has been detected on builder elfutils-debian-amd64 while 
building elfutils.

Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/52/builds/524

Build state: build successful
Revision: 7857383e2e9e7f87c447562263a567e24d0718c1
Worker: bb2-1
Build Reason: (unknown)
Blamelist: Aaron Merey , Mark Wielaard , 
Michal Sekletar 

Steps:

- 0: worker_preparation ( success )

- 1: set package name ( success )

- 2: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/2/logs/stdio

- 3: autoreconf ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/3/logs/stdio

- 4: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/4/logs/stdio
- config.log: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/4/logs/config_log

- 5: get version ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/5/logs/stdio
- property changes: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/5/logs/property_changes

- 6: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/6/logs/stdio
- warnings (3): 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/6/logs/warnings__3_

- 7: make check ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/7/logs/stdio
- test-suite.log: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/7/logs/test-suite_log

- 8: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/8/logs/stdio

- 9: build bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/9/logs/stdio

- 10: fetch bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/10/logs/stdio

- 11: unpack bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/11/logs/stdio

- 12: pass .bunsen.source.* ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/12/logs/stdio

- 13: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/13/logs/stdio

- 14: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/14/logs/stdio

- 15: make distclean ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#/builders/52/builds/524/steps/15/logs/stdio



Re: [PATCH] doc: Update elf_begin.3

2025-06-04 Thread Mark Wielaard
Hi Aaron,

On Mon, 2025-06-02 at 21:22 -0400, Aaron Merey wrote:
> Signed-off-by: Aaron Merey 
> ---
>  doc/elf_begin.3 | 104 
>  1 file changed, 79 insertions(+), 25 deletions(-)
> 
> diff --git a/doc/elf_begin.3 b/doc/elf_begin.3
> index 6a1d0c27..cddd181f 100644
> --- a/doc/elf_begin.3
> +++ b/doc/elf_begin.3
> @@ -1,37 +1,91 @@
> -.\" Modified Thu Sep 5 2017 by Ben Woodard 
> -.\"
> -.TH ELF_BEGIN 3 2017-09-05 "Libelf" "Libelf Programmer's Manual"
> +.TH ELF_BEGIN 3 2025-06-02 "Libelf" "Libelf Programmer's Manual"
> +
>  .SH NAME
> -elf_begin \- Return descriptor for ELF file.
> -.nf
> +elf_begin \- initialize an ELF descriptor
>  .SH SYNOPSIS
> -.B #include 
> -.sp
> -.BI "Elf *elf_begin (int " filedes ", Elf_Cmd " cmd ", Elf *" ref ");"
> -.BI "Elf *elf_clone (int " filedes ", Elf_Cmd " cmd ");"
> -.BI "int elf_end (Elf *" elf ");"
> +.nf
> +#include 
> +
> +Elf *elf_begin(int fildes, Elf_Cmd cmd, Elf *ref);
>  .fi

OK, just describes elf_begin now.

>  .SH DESCRIPTION
> -The
> -.BR elf_begin ()
> +Initialize and return a handle to an ELF file for use with the elfutils
> +\fBlibelf\fP library and related elfutils libraries such as \fBlibdw\fP.
> +
> +The returned \fBElf\fP descriptor must be released using \fBelf_end(3)\fP.
> +
> +\fBelf_version(3)\fP must be called before using any \fBlibelf\fP library
> +including \fBelf_begin(3)\fP.
> +
> +.SH PARAMETERS
> +.TP
> +\fIfildes\fP
> +A file descriptor referring to an ELF object. The descriptor should be open
> +for reading, and optionally for writing, depending on the intended operation.

May be -1 when also given a ref (or must be the same fd as the fd
associated with ref)?

> +.TP
> +\fIcmd\fP
> +Specifies the action to perform. Common values include:
> +.RS
> +.TP
> +\fBELF_C_NULL\fP
> +Return a NULL pointer instead of initializing an ELF descriptor.

I didn't believe this, but it is true. How useless...
Maybe mention it also ignores ref?

> +.TP
> +\fBELF_C_READ\fP
> +Open an ELF descriptor for reading.
> +.TP
> +\fBELF_C_READ_MMAP\fP
> +Open an ELF descriptor for reading using mmap, if available.
> +.TP
> +\fBELF_C_READ_MMAP_PRIVATE\fP
> +Open an ELF descriptor for reading using mmap, if available.  This command
> +invokes mmap with MAP_PRIVATE whereas the other \fB*_MMAP\fP commands invoke
> +mmap with MAP_SHARED.  See \fBmmap(2)\fP for more information.
> +.TP
> +\fBELF_C_WRITE\fP
> +Open an ELF descriptor for writing.  The descriptor initially refers to an
> +empty file.
> +.TP
> +\fBELF_C_WRITE_MMAP\fP
> +Open an ELF descriptor for writing using mmap, if available.  The descriptor
> +initially refers to an empty file.
> +.TP
> +\fBELF_C_RDWR\fP
> +Open an ELF descriptor for reading and writing.
> +.TP
> +\fBELF_C_RDWR_MMAP\fP
> +Open an ELF descriptor for reading and writing using mmap, if available.

Maybe sort the MMAP variants last as a group?
Maybe mention The MMAP variants are an elfutils libelf extension
possibly not available with other libelf implementations?

Also once the mmap size is set it might fail to extend the size if
mremap cannot grow the mmap in place. This is a real problem that make
ELF_C_RDWR_MMAP often only useful for in-place changes or removing
data. Don't know how to best add this warning. How to use the MMAP
variants is kind of tricky.

> +.RE
> +.TP
> +\fIref\fP
> +A reference to an existing \fBElf\fP descriptor. If not \fBNULL\fP, this 
> will be
> +used to duplicate a previous ELF descriptor.  \fIref\fP must have been opened
> +with read/write permissions consistent with \fIcmd\fP.
> +

Should mention that if the ref is an AR file it will return an Elf
descriptor for the next available object member (see elf_next?). And
that otherwise ref is returned with the reference count updated, so to
dispose of it you need to call elf_end one extra time (see elf_end?).

>  .SH RETURN VALUE
> -.SH ERRORS
> -elf_begin ELF_E_NO_VERSION ELF_E_INVALID_FILE ELF_E_INVALID_CMD ELF_E_NOMEM
> -elf_clone ELF_E_NOMEM
> -elf_end
> +On success, \fBelf_begin()\fP returns a pointer to a new Elf descriptor.

Except if the command is ELF_NULL, and when ref is given and it isn't
an AR file, ref is returned (with the reference count updated).

> +On failure, it returns \fBNULL\fP and sets an internal error state that can 
> be
> +retrieved with \fBelf_errmsg(3)\fP.
> +
> +.SH SEE ALSO
> +.BR mmap (2),
> +.BR elf_end (3),
> +.BR elf_clone (3),
> +.BR libelf (3),
> +.BR elf (5)
> +

Maybe add elf_next and elf_rand to explain the behavior when the Elf
descriptor (or ref) is an AR file?

>  .SH ATTRIBUTES
> -For an explanation of the terms used in this section, see
> -.BR attributes (7).
>  .TS
>  allbox;
> -lbw29 lb lb
> +lbx lb lb
>  l l l.
> -Interface   Attribute   Value
> +InterfaceAttribute   Value
>  T{
> -.BR elf_begin (),
> -.BR elf_clone (),
> -.BR elf_end ()
> -T}  Thread safety   MT-Safe
> +.na
> +.nh
> +.BR elf_begin ()
> +T}   Thread safety   MT-Safe
>  .TE
>  
> -.S