https://sourceware.org/bugzilla/show_bug.cgi?id=34062
Bug ID: 34062
Summary: CWE-843 type confusion in
elf64_ia64_hash_copy_indirect() causes invalid free —
DoS via malformed IA-64 ELF
Product: binutils
Version: 2.46
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: takaosato1997 at gmail dot com
Target Milestone: ---
Created attachment 16685
--> https://sourceware.org/bugzilla/attachment.cgi?id=16685&action=edit
payload file
## Summary
**CWE-843 (Type Confusion) + CWE-590 (Free of Memory Not on the Heap)**
A type confusion vulnerability exists in `bfd/elfnn-ia64.c` in the function
`elf64_ia64_hash_copy_indirect()`. When GNU ld processes a malformed ELF-64
IA-64
object file while operating in x86_64 emulation mode, the IA-64 backend casts
an
`elf_x86_link_hash_entry` (allocated by the x86_64 subsystem) to
`elfNN_ia64_link_hash_entry` (expected by the IA-64 backend). Due to a struct
layout
overlap, the `info` pointer field of the IA-64 struct (offset 160) reads the
`plt_second.offset` sentinel value `(bfd_vma)-1 = 0xffffffffffffffff` from the
x86_64 struct. The function then calls `free(0xffffffffffffffff)`, causing an
immediate SIGSEGV. Confirmed reproducible in both ASAN and optimized release
builds.
| Field | Value |
|---------------|------------------------------------------------------------|
| **CWE** | **CWE-843** (Type Confusion) + **CWE-590** (Free of Memory
Not on the Heap) |
| **CVSS v3.1** | **5.5 MEDIUM** — AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H |
| Component | GNU Binutils — libbfd / ELF IA-64 linker backend |
| File | bfd/elfnn-ia64.c |
| Function | elf64_ia64_hash_copy_indirect() |
| Line | 1311 |
| Bug type | Type Confusion → Invalid Free
|
| Affected | binutils 2.46, HEAD (confirmed unpatched) |
| Trigger | Any ld build with IA-64 target support
(`--enable-targets=all`) |
| PoC | `payload.o` — 7360-byte malformed ELF-64 IA-64 object file
|
| Duplicate? | No — distinct from Bug-001 (XCOFF OOB-WRITE) and Bug-004
(XCOFF OOB-READ) |
---
## Root Cause
### The type confusion — struct layout overlap at offset 160
When BFD opens an ELF-64 IA-64 input file, it selects the IA-64 backend
(`elf64_bed`)
for file-specific operations — even if the linker is running with x86_64
emulation.
The linker's global symbol hash table was initialized by the x86_64 emulation,
which
allocates hash entries of type `elf_x86_link_hash_entry` (176 bytes) via the
x86_64
`hash_newfunc`. The IA-64 backend expects entries of type
`elfNN_ia64_link_hash_entry`,
which has a different layout despite sharing the same base struct.
**`elf_x86_link_hash_entry` layout (x86_64, allocated by linker):**
```
[ 0] struct elf_link_hash_entry elf ↠144 bytes base struct
[144] unsigned char tls_type ↠1 byte
[145] bitfields (zero_undefweak, etc.) ↠3 bytes
[148] (4 bytes padding / implicit)
[152] union gotplt_union plt_got ↠8 bytes; init to (bfd_vma)-1
[160] union gotplt_union plt_second ↠8 bytes; init to (bfd_vma)-1
↠OVERLAP
[168] bfd_vma tlsdesc_got ↠8 bytes
```
**`elfNN_ia64_link_hash_entry` layout (IA-64, expected by backend):**
```
[ 0] struct elf_link_hash_entry root ↠144 bytes base struct
[144] unsigned int count ↠4 bytes
[148] unsigned int sorted_count ↠4 bytes
[152] unsigned int size ↠4 bytes
[156] (4 bytes alignment padding)
[160] struct elfNN_ia64_dyn_sym_info *info ↠8 bytes ↠OVERLAP with
plt_second
```
**Field overlap at offset 160 (verified via GDB):**
The `info` pointer that the IA-64 backend reads and passes to `free()` is the
**same 8 bytes** as `plt_second.offset` in the x86_64 struct. The x86_64 linker
initializes `plt_second.offset` to the sentinel `(bfd_vma)-1 =
0xffffffffffffffff`
(indicating "no PLT.GOT entry assigned yet"). The IA-64 backend reads this as
the
`info` pointer and calls `free(0xffffffffffffffff)`.
### Vulnerable code path
```
eld_link_add_object_symbols() elflink.c:5508
→ _bfd_elf_add_default_symbol() elflink.c:2140
→ (*bed->elf_backend_copy_indirect_symbol)() ↠uses INPUT FILE'S
IA-64 backend
→ elf64_ia64_hash_copy_indirect() elfnn-ia64.c:1282
```
In `elf64_ia64_hash_copy_indirect()`:
```c
static void
elf64_ia64_hash_copy_indirect (struct bfd_link_info *info,
struct elf_link_hash_entry *xdir,
struct elf_link_hash_entry *xind)
{
struct elfNN_ia64_link_hash_entry *dir, *ind;
dir = (struct elfNN_ia64_link_hash_entry *) xdir; // ↠UNSAFE CAST
ind = (struct elfNN_ia64_link_hash_entry *) xind; // ↠UNSAFE CAST
/* xdir and xind are actually elf_x86_link_hash_entry structs,
not elfNN_ia64_link_hash_entry. The cast is invalid. */
if (ind->info != NULL) // ind->info = plt_second.offset =
0xffffffffffffffff → true!
{
free (dir->info); // LINE 1311: free(plt_second.offset) =
free(0xffffffffffffffff)
// ↑ INVALID FREE → SIGSEGV
dir->info = ind->info;
...
```
The cast at lines 1288–1289 is unchecked. No validation is performed to
confirm that
`xdir` and `xind` are genuinely `elfNN_ia64_link_hash_entry` instances
(allocated by
the IA-64 `elfNN_ia64_link_hash_newfunc`). When the linker emulates x86_64, all
hash
entries are `elf_x86_link_hash_entry`, but the IA-64 backend is still invoked
for
IA-64 input files, causing the type confusion.
### GDB-confirmed values at crash point
```
Crash frame: elf64_ia64_hash_copy_indirect elfnn-ia64.c:1311
free (dir->info)
dir (pointer to hash entry) = 0x521000016f40 ↠x86_64
elf_x86_link_hash_entry
ind (pointer to hash entry) = 0x521000016ff8 ↠x86_64
elf_x86_link_hash_entry
Inspecting dir memory at known offsets:
[offset 144] x86 tls_type + bitfields = 0x0000000000000100 (IA64 reads as
count=256)
[offset 152] x86 plt_got.offset = 0xffffffffffffffff (IA64 reads as
size=4294967295)
[offset 160] x86 plt_second.offset = 0xffffffffffffffff ↠dir->info
(IA64 view)
free(dir->info) = free(0xffffffffffffffff) → SIGSEGV
```
**Struct size verification (GDB, binutils-2.46-asan/ld/ld-new):**
```
sizeof(struct elf_link_hash_entry) = 144 bytes
sizeof(struct elf_x86_link_hash_entry) = 176 bytes
plt_got at offset 152
plt_second at offset 160 ↠overlaps IA64 info
```
---
## ASAN Report
```
=================================================================
==3639582==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffffffffffef
(pc 0x5c6ba65ccbc6 bp 0x000000000000 sp 0x7ffeb7a45df0 T0)
==3639582==The signal is caused by a WRITE memory access.
#0 __asan::Allocator::Deallocate(void*, unsigned long, unsigned long,
__sanitizer::BufferedStackTrace*, __asan::AllocType)
(/home/fuzzer/targets/binutils-2.46-asan/ld/ld-new+0x2277bc6)
#1 free
(/home/fuzzer/targets/binutils-2.46-asan/ld/ld-new+0x23103df)
#2 elf64_ia64_hash_copy_indirect
/home/fuzzer/targets/binutils-2.46/bfd/elfnn-ia64.c:1311:7
#3 _bfd_elf_add_default_symbol
/home/fuzzer/targets/binutils-2.46/bfd/elflink.c:2140:7
#4 elf_link_add_object_symbols
/home/fuzzer/targets/binutils-2.46/bfd/elflink.c:5508:11
#5 bfd_elf_link_add_symbols
/home/fuzzer/targets/binutils-2.46/bfd/elflink.c:6454:14
#6 load_symbols ld/ldlang.c:3223:7
#7 open_input_bfds ld/ldlang.c:3717:13
#8 lang_process ld/ldlang.c:8386:3
#9 main ld/ldmain.c:958:3
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/home/fuzzer/targets/binutils-2.46-asan/ld/ld-new+0x2277bc6)
in __asan::Allocator::Deallocate(...)
==3639582==ABORTING
```
**Note on address discrepancy:** ASAN reports `0xffffffffffffffef` (not
`0xffffffffffffffff`) because `Allocator::Deallocate` subtracts the ASAN chunk
header size (16 bytes) from the user pointer before writing shadow metadata:
`0xffffffffffffffff - 16 = 0xffffffffffffffef`. This is consistent with
`dir->info = 0xffffffffffffffff` observed directly in GDB.
---
## Release Build Behavior
```bash
$ /home/fuzzer/targets/binutils-2.46-release/ld/ld-new \
--gc-sections -o /dev/null crash_min.o
/home/fuzzer/targets/binutils-2.46-release/ld/ld-new: warning: crash_min.o:
unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
/home/fuzzer/targets/binutils-2.46-release/ld/ld-new: crash_min.o:
in function `grp2_func': seed_groups.c:(.text.grp3+0x0):
multiple definition of `grp2_func'; ...
Segmentation fault (core dumped)
[exit code 139]
```
No ASAN instrumentation required. The crash is reproducible with any optimized
build of ld that includes IA-64 target support.
---
## PoC
**Attached:** `payload.o` — 7360-byte malformed ELF-64 IA-64 relocatable
object.
### Reproduce:
```bash
# Release build — immediate SIGSEGV, no special flags:
ld --gc-sections -o /dev/null payload.o
# → Segmentation fault (core dumped), exit 139
# ASAN build — full sanitizer trace:
ASAN_OPTIONS="halt_on_error=0:print_stacktrace=1" \
ld --gc-sections -o /dev/null payload.o
# → SEGV in __asan::Allocator::Deallocate via free() in
elf64_ia64_hash_copy_indirect
```
### Requirements:
- ld built with `--enable-targets=all` (includes IA-64 ELF support)
- Standard binutils build on any x86_64 host
### What the PoC does:
1. ELF magic identifies the file as IA-64 (`EM_IA64 = 50`, machine = `0x0032`)
2. BFD selects the IA-64 backend (`elf64_bed`) for this input file
3. Symbol table contains two definitions of `grp2_func` (in `.text.grp2` and
`.text.grp3`)
4. The multiple-definition handling path calls `_bfd_elf_add_default_symbol()`,
which
invokes `(*bed->elf_backend_copy_indirect_symbol)` using the IA-64 backend
5. `elf64_ia64_hash_copy_indirect` receives x86_64 hash entries, reads
`plt_second.offset = 0xffffffffffffffff` as `dir->info`, calls `free()` →
crash
---
## Exploitability Analysis
### Immediate impact — confirmed DoS
`free(0xffffffffffffffff)` unconditionally crashes. Every invocation of `ld` on
the PoC file produces SIGSEGV in both release and ASAN builds. The crash is
deterministic and requires no race condition or heap state preparation.
### The freed pointer — is it controllable?
The value `0xffffffffffffffff = (bfd_vma)-1` is the **initialization sentinel**
for
`plt_second.offset` in `elf_x86_link_hash_entry`, set in
`elf_x86_link_hash_newfunc`.
This sentinel would be overwritten if `check_relocs` or `size_dynamic_sections`
ran
before `elf64_ia64_hash_copy_indirect`. Source-code analysis confirms this does
NOT happen.
**Execution order in `lang_process()` (verified in ldlang.c and elf.em):**
```
line 8386: open_input_bfds()
└─ elf_link_add_object_symbols()
└─ _bfd_elf_add_default_symbol()
└─ elf64_ia64_hash_copy_indirect()
└─ free(0xffffffffffffffff) ↠CRASH
line 8610: lang_check_relocs() ↠runs AFTER the crash
└─ check_relocs() ↠would set plt_second.refcount, never
reached
```
The x86_64 emulation (`elf.em:87`) sets `check_relocs_after_open_input = true`,
meaning `check_relocs` is deferred to after `open_input_bfds`. The crash occurs
inside `open_input_bfds`. Therefore:
- `plt_second.offset` is **always** `(bfd_vma)-1 = 0xffffffffffffffff` at crash
time
- The freed pointer is **not attacker-controllable**
- No known path makes `plt_second.offset` hold a heap address before the crash
**Assessment:** The vulnerability is a reliable, deterministic DoS. The type
confusion
causes `free()` of a non-heap address, resulting in unconditional SIGSEGV. No
memory
corruption primitive is reachable with the current bug trigger path.
### CWE classification
- **CWE-843**: Type Confusion — IA-64 backend casts x86_64 hash entry to
IA-64 type
- **CWE-590**: Free of Memory Not on the Heap — `free(0xffffffffffffffff)`
(unreachable address)
- **CWE-704**: Incorrect Type Conversion — root cause enabling the invalid
free
---
## Security Impact
| Aspect | Assessment
|
|----------------------|-----------------------------------------------------------|
| Attack vector | Local — supply chain (malicious .o in build
dependency) |
| Trigger | User runs `ld` on attacker-controlled IA-64 .o file
|
| Target platform | Any host running `ld --enable-targets=all` (default
Fedora/RHEL builds) |
| Minimum impact | Reliable crash / DoS of the linker process
|
| Maximum impact | Heap corruption → potential code execution (see
above) |
| Privilege escalation | If ld runs in a CI/CD pipeline, crash stops the build;
|
| | if running as root in a build container, higher impact
|
| Supply chain risk | High — malicious .o in a package archive (.a)
silently |
| | processed during project build
|
**Real-world scenario:** An attacker publishes a library package containing a
malicious IA-64 ELF object file embedded in an archive (`.a`). Any developer or
CI system that links against this package crashes the linker with SIGSEGV
during
the build step. In a hardened pipeline (no ASLR bypass, no heap info leak), the
impact is DoS. With additional constraints relaxed, the controlled-free
primitive
could be escalated toward code execution.
---
## CVSS v3.1
```
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H
```
| Metric | Value | Rationale
|
|-------------------------|-------|--------------------------------------------------|
| Attack Vector | L | Must provide object file to linker
|
| Attack Complexity | L | Single malformed file, no heap layout
knowledge required |
| Privileges Required | N | No special privileges
|
| User Interaction | R | User must invoke ld on the file
|
| Scope | U | Impact limited to linker process
|
| Confidentiality Impact | N | No information disclosure
|
| Integrity Impact | N | Freed pointer not controllable — no heap
corruption |
| Availability Impact | H | Confirmed SIGSEGV crash of linker, 100%
reliable |
**Base Score: 5.5 (MEDIUM)**
---
## Affected Versions
- **binutils 2.46** — confirmed vulnerable
- **binutils HEAD** (master, 2026-04-09) — confirmed unpatched (identical
code in elfnn-ia64.c)
- **Earlier versions** — likely affected (elf64_ia64_hash_copy_indirect
exists since IA-64 support was added)
- **Builds with `--enable-targets=all`** — affected (default in Fedora, RHEL,
Debian, Ubuntu `binutils-multiarch`)
---
## Not a Duplicate
This bug is distinct from all known binutils vulnerabilities in this campaign:
| Bug | Location | Type | Root Cause |
|-----|----------|------|------------|
| Bug-001 | xcofflink.c:1416 | heap OOB WRITE | XCOFF target_index >
section_count |
| Bug-004 | xcofflink.c:1589 | heap OOB READ | XCOFF unvalidated n_numaux |
| **Bug-005 (this)** | **elfnn-ia64.c:1311** | **Invalid free** |
**IA-64/x86-64 backend type confusion** |
Different file format (ELF vs XCOFF), different backend, different CWE
classification,
different root cause. No existing XCOFF CVE covers this path.
Searching public databases: no CVE references `elf64_ia64_hash_copy_indirect`
with
this type confusion mechanism. This appears to be a previously unreported
issue.
---
## Proposed Fix
The root cause is that `elf64_ia64_hash_copy_indirect` performs unsafe casts
without
validating that the hash entries were actually allocated by the IA-64 backend.
**Option A — Guard with NULL check on info before freeing** (minimal, safe):
```c
/* elfnn-ia64.c:1311 — before calling free() */
if (ind->info != NULL)
{
- free (dir->info);
+ /* Only free if dir->info was properly initialized by
elfNN_ia64_link_hash_newfunc.
+ When the linker operates in non-IA64 emulation mode, dir is an
elf_x86_link_hash_entry
+ cast to elfNN_ia64_link_hash_entry; the info field reads
plt_second.offset = (bfd_vma)-1.
+ Freeing that sentinel is invalid. */
+ if (dir->info != NULL && dir->info != (struct elfNN_ia64_dyn_sym_info
*)(bfd_vma)-1)
+ free (dir->info);
dir->info = ind->info;
```
**Option B — Check the link hash table type before casting** (correct,
thorough):
```c
/* elfnn-ia64.c:1282 — at function entry */
static void
elf64_ia64_hash_copy_indirect (struct bfd_link_info *info,
struct elf_link_hash_entry *xdir,
struct elf_link_hash_entry *xind)
{
struct elfNN_ia64_link_hash_entry *dir, *ind;
+ /* Guard: this backend function should only be called when the output
+ target is IA-64. If the hash table was initialized by a different
+ emulation, the entries are not elfNN_ia64_link_hash_entry and the
+ cast below is invalid. */
+ {
+ struct elf_link_hash_table *htab = elf_hash_table (info);
+ const struct elf_backend_data *bed = get_elf_backend_data (htab->dynobj);
+ if (bed == NULL || bed->elf_machine_code != EM_IA_64)
+ return;
+ }
+
dir = (struct elfNN_ia64_link_hash_entry *) xdir;
ind = (struct elfNN_ia64_link_hash_entry *) xind;
```
**Option B is preferred** as it prevents all IA-64 backend functions from
operating
on non-IA-64 hash entries, not just the free() call.
---
--
You are receiving this mail because:
You are on the CC list for the bug.
