A flaw was found in binutils. A heap-buffer-overflow vulnerability exists when processing a specially crafted XCOFF (Extended Common Object File Format) object file during linking. A local attacker could trick a user into processing this malicious file, which could lead to arbitrary code execution, allowing the attacker to run unauthorized commands, or caus…
GNU Binutils thru 2.46 readelf contains a null pointer dereference vulnerability when processing a crafted ELF binary with malformed header fields. During relocation processing, an invalid or null section pointer may be passed into display_relocations(), resulting in a segmentation fault (SIGSEGV) and abrupt termination. No evidence of memory corruption bey…
GNU Binutils thru 2.46 readelf contains a double free vulnerability when processing a crafted ELF binary with malformed relocation data. During GOT relocation handling, dump_relocations may return early without initializing the all_relocations array. As a result, process_got_section_contents() may pass an uninitialized r_symbol pointer to free(), leading to…
GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF .debug_rnglists data. A logic flaw in the DWARF parsing path causes readelf to repeatedly print the same warning message without making forward progress, resulting in a non-terminating output loop that requires manual interruptio…
GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF loclists data. A logic flaw in the DWARF parsing code can cause readelf to repeatedly print the same table output without making forward progress, resulting in an unbounded output loop that never terminates unless externally inte…
GNU Binutils thru 2.46 readelf contains a vulnerability that leads to an abort (SIGABRT) when processing a crafted ELF binary with malformed DWARF abbrev or debug information. Due to incomplete state cleanup in process_debug_info(), an invalid debug_info_p state may propagate into DWARF attribute parsing routines. When certain malformed attributes result in…
Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug information. A logic error in the handling of DWARF compilation units can result in an invalid offset_size value being used inside byte_get_little_endian, leading to an abort (SIGABRT). The issue was observed in binutils 2.44. A local atta…
Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug_rnglists data. A logic error in the handling of the debug_rnglists header can cause objdump to repeatedly print the same warning message and fail to terminate, resulting in an unbounded logging loop until the process is interrupted. The is…
GNU Binutils thru 2.46 readelf contains a vulnerability that leads to an invalid pointer free when processing a crafted ELF binary with malformed relocation or symbol data. If dump_relocations returns early due to parsing errors, the internal all_relocations array may remain partially uninitialized. Later, process_got_section_contents() may attempt to free …
An issue was discovered in Binutils before 2.46. The objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed debug information. A logic flaw in the handling of DWARF location list headers can cause objdump to enter an unbounded loop and produce endless output until manually interrupted. This issue affects versions …
A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to …
A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is…
A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is n…
A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is…
A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recomme…
A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be us…
VuXML only (0) · listed, port not fixed yet
None. pkg audit reports nothing for this version.
Fixed (2)
VuXML entries whose affected range this version has left.
Enable -shared support for embedded RISC-V targets
Shared library support is incomplete for the RISC-V embedded elf
targets, and was disabled some time ago [1]. However, it appears that it
is functional enough to support basic usage, and is required to
successfully build u-boot for RISC-V. This toolchain doesn't have
widespread usage, so any risk of re-enabling this support is outweighed
by the benefit of being able to build important ports like u-boot.
Override this default.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=be1dce26256aa9f6c7742e81c8c3db9eacff079d
Reviewed by: philip
Approved by: philip
Differential Revision: https://reviews.freebsd.org/D25735
devel/binutils: enable gold on powerpc64 and powerpc
ld.gold now works fine on powerpc64, but only when compiled with clang.
PR: 243194
Approved by: bapt (maintainer timeout)
Add a riscv64_none_elf flavor to devel/binutils.
This flavor of binutils can be used as an external toolchain for
riscv64 bare metal.
Submitted by: kp
Sponsored by: Axiado
Approved by: bapt (maintainer)
Fix gas for FreeBSD/sparc64.
Since binutils 2.30, gas treated FreeBSD/sparc64 the same as NetBSD
and OpenBSD and generated incorrect code as a result.
PR: 243119
Submitted by: Michael Reim
Reviewed by: bapt (maintainer), emaste
Differential Revision: https://reviews.freebsd.org/D23087
Add a powerpc flavor to devel/binutils.
This flavor of binutils can be used as an external toolchain for
32-bit powerpc.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D22862
Update binutils to 2.33.1
While here, convert binutils into flavors, that ease a lot maintenance
and helps cleaning out the code.
This is inspired by the same work on going on the xtoolchained gcc by jhb@
PR: 241756
Exp-run: antoine (portmgr)
Discussed with: jhb
Differential Revision: https://reviews.freebsd.org/D22258
Remove binutils-do-not-provide-shared-section-symbols.patch, the issue it was working around was fixed in binutils version 2.32
PR: 237068
Submitted by: dim
Permit base/binutils to be built as a native package.
- Don't require CROSS_TOOLCHAIN and CROSS_SYSROOT for base/binutils.
- Fix some places in devel/binutils to test the PREFIX instead of
CROSS_TOOLCHAIN to determine if base/binutils is being built.
- When base/binutils is built natively, the binaries are installed
with the target name prefix already.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D19128
Turn on threads support, mainly for ld.gold. In my tests with llvm this actually worked better than no threads, and threads are turned on in other packaging distributions. Have been using this for a while and it looks like the more tested config upstream.
Reviewed-by: bapt (back in June)
Install texinfo files (GNU info) into ${PREFIX}/share/info
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
Cleanup packing lists.
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
- Drop plist entries from devel/binutils that are now properly removed.
Previously the binaries for Windows tools like dlltool were removed
from the staging area but the manpages were still left in the package.
- Bump PORTREVISION.
This is a recommit of r476186 but with the update to the pkg-plist of
devel/binutils and PORTREVISION bump.
PR: 230278
Reviewed by: antoine
Differential Revision: https://reviews.freebsd.org/D16582
base/binutils: Cleanup packing lists.
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
Approved by: bapt (implicit for base/*)
Differential Revision: https://reviews.freebsd.org/D16464
Add ports for an i386 external GCC toolchain.
- devel/binutils: Remove i386 a.out linker scripts when building
i386-binutils or a base/binutils that targets i386.
- devel/powerpc64-gcc: Remove float.h on i386 since it conflicts
with sys/x86/include/float.h.
- devel/i386-{binutils,gcc,xtoolchain}: New ports.
Reviewed by: bapt (previous version)
Differential Revision: https://reviews.freebsd.org/D16228
Fix cross build of base/ ports
This is a follow up to r461057 and fixes base/binutils and base/gcc in my
testing.
PR: 224217
Submitted by: nwhitehorn (partially, I made additional changes)
Reviewed by: bapt
Begin deorbit burn of ia64. We have not attempted to build packages for it for many years.
While here, alphabetize ARCHs, pet portlint, and modernize usages.
Approved by: portmgr (tier-2 blanket)
Build aarch64-binutils as static by default.
This is required to build Arm64 packages using QEMU. Poudriere copies
the native ld from the host into the jail and uses that during the build.
This only works if ld is static.
Reported by: krion
Approved by: bapt
Fix booting the arm64 kernel when built with clang 3.9.0
Clang 3.9.0 changes how weak extern is handled. They now use the got to
handle them. This is a problem as ld.bfd doesn't fill out any default value
in the got so pointers become NULL. This caused the kernel to fail to boot
as we use this in linker sets.
This fixes the issue by setting a default value in the got. The kernel
still loads data through it, but because we always load it at a fixed
virtual address the address it finds is valid.
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D8622