REDHAT-BUG-2558338: Medium severity Red Hat OpenShift CLI (oc) vulnerability

A flaw was found in openshift/oc's local tar-extraction code used by oc image extract. The createTarFile() function in pkg/cli/image/archive/archive.go (oc's private fork of Docker/Moby's pkg/archive) validates that a symlink or hardlink target stays inside the extraction directory by computing targetPath := filepath.Join(filepath.Dir(path), hdr.Linkname) and testing strings.HasPrefix(targetPath, extractDir), but then creates the symlink using the raw, unvalidated hdr.Linkname via os.Symlink(hdr.Linkname, path). The check fails in two independent ways: for an absolute Linkname (e.g. /etc/passwd), Go's filepath.Join does not re-root, so the computed path folds under the extraction directory and passes, while the created symlink points to the attacker-specified absolute path; and for a relative Linkname sharing the destination's basename as a text prefix (e.g. ../safe-x/marker against a safe destination), strings.HasPrefix matches across the path boundary and the target resolves into a sibling directory outside the destination. The hardlink (TypeLink) branch is affected by the sibling-prefix variant. oc image extract reaches this code by calling archive.ApplyLayer() directly with a reader sourced from the remote image's layer blob, so the processed tar stream is attacker-controlled. The dangling-symlink primitive further chains into an arbitrary-content write outside the destination: a second tar entry whose name traverses the just-planted symlink is written with OpenFile(path, OCREATE|OWRONLY, …), which follows symlinks, because the per-entry name check inspects only the textual dest+Name join and never Lstats intermediate components. The general entry-name containment check in the same file is correct (it uses filepath.Rel); only the symlink/hardlink target check was left in the older, insufficient form.