Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • iucode-tool iucode-tool
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • iucode-tooliucode-tool
  • iucode-tooliucode-tool
  • Issues
  • #3
Closed
Open
Issue created Jan 13, 2017 by Henrique de Moraes Holschuh@hmhOwner

CVE-2017-0357: iucode-tool: heap buffer overflow on -tr loader

The bug affects a somewhat obscure feature of iucode_tool, the "recovery" microcode loader, accessed through the "-tr" command line switch. The microcode recovery loader is typically used to inspect or extract microcodes directly from kernel images, initramfs images, etc.

The -tr loader works by reading the entire datafile in memory (it imposes a hard limit of 1GiB worth of data), then scanning that memory forwards for microcode regions (a region is one or more microcodes adjacent to each other), and packing any it finds at the begginning of the memory buffer to create a single microcode region. When it finishes, it realloc()s the memory buffer to its new size.

When a valid microcode is present at the end of the data file and there is no extra data after it, intel_ucode_scan_for_microcode() would fail to detect the end-of-buffer situation, and read data past the end of the memory buffer looking for an adjacent valid microcode.

This is usually harmless, as typically there will not be a valid microcode update exactly right past the end of the memory buffer.

Unfortunately, should there be a valid microcode exactly after the memory buffer, iucode_tool will misbehave very badly. A SIGSEGV is the best result one could expect. Heap corruption can happen if further, non-adjacent microcodes are found in memory as iucode_tool will use memmove() to compact them into a single region, possibly overwriting the heap memory past the end of the buffer.

Issue present since: v1.4

Issue fixed in: v2.1.1

Minimum fix for iucode-tool from v1.4 to v2.1

Assignee
Assign to
Time tracking