[Clang][Driver] Use-after free in CreateOffloadingDeviceToolChains

[Meinersbur]

For deducing offload triples, the driver creates some temporary ToolChains here:

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1044 to 1047 in e4a8969

	auto TempTC = std::make_unique<toolchains::CudaToolChain>(
	*this, *NVPTXTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1051 to 1054 in e4a8969

	auto TempTC = std::make_unique<toolchains::AMDGPUOpenMPToolChain>(
	*this, *AMDTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

The problem is that the ToolChain is used to index into a cache here:

llvm-project/clang/lib/Driver/Compilation.cpp

Line 63 in c979ce7

DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];

It is possible that the temporary ToolChains are allocated at the same address. In that case the derived arguments for CudaToolChain are reused for AMDGPUOpenMPToolChain.

Causes the flakiness of the offload-Xarch.c test case here: https://lab.llvm.org/buildbot/#/builders/81/builds/5233
Other complains here: #126248

Temporay Toolchains introduced here: a17ab7a

Btw, it is super risky to use StringRef as map index type. Instantiating temporary toolchains is not common, but temporary strings definitely are.

llvm-project/clang/lib/Driver/Driver.cpp

Line 2570 in c979ce7

C.getArgsForToolChain(&TC, Triple.getArchName(), Action::OFK_None);

would be one. More bugs be waiting.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Michael Kruse (Meinersbur)

For deducing offload triples, the driver creates some temporary ToolChains here:

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1044 to 1047 in e4a8969

	auto TempTC = std::make_unique<toolchains::CudaToolChain>(
	*this, *NVPTXTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1051 to 1054 in e4a8969

	auto TempTC = std::make_unique<toolchains::AMDGPUOpenMPToolChain>(
	*this, *AMDTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

The problem is that the ToolChain is used to index into a cache here:

llvm-project/clang/lib/Driver/Compilation.cpp

Line 63 in c979ce7

DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];

It is possible that the temporary ToolChains are allocated at the same address. In that case the derived arguments for CudaToolChain are reused for AMDGPUOpenMPToolChain.

Causes the flakiness of the offload-Xarch.c test case here: https://lab.llvm.org/buildbot/#/builders/81/builds/5233
Other complains here: #126248

Temporay Toolchains introduced here: a17ab7a

Btw, it is super risky to use a StringRef as map index type. Instantiating temporary toolchains is not common, but temporary strings definitely are.

llvm-project/clang/lib/Driver/Driver.cpp

Line 2570 in c979ce7

C.getArgsForToolChain(&TC, Triple.getArchName(), Action::OFK_None);

would be one. More bugs be waiting.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Michael Kruse (Meinersbur)

For deducing offload triples, the driver creates some temporary ToolChains here:

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1044 to 1047 in e4a8969

	auto TempTC = std::make_unique<toolchains::CudaToolChain>(
	*this, *NVPTXTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

llvm-project/clang/lib/Driver/Driver.cpp

Lines 1051 to 1054 in e4a8969

	auto TempTC = std::make_unique<toolchains::AMDGPUOpenMPToolChain>(
	*this, *AMDTriple, *HostTC, C.getInputArgs());
	for (StringRef Arch : getOffloadArchs(
	C, C.getArgs(), Action::OFK_OpenMP, &*TempTC, true))

The problem is that the ToolChain is used to index into a cache here:

llvm-project/clang/lib/Driver/Compilation.cpp

Line 63 in c979ce7

DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];

It is possible that the temporary ToolChains are allocated at the same address. In that case the derived arguments for CudaToolChain are reused for AMDGPUOpenMPToolChain.

Causes the flakiness of the offload-Xarch.c test case here: https://lab.llvm.org/buildbot/#/builders/81/builds/5233
Other complains here: #126248

Temporay Toolchains introduced here: a17ab7a

Btw, it is super risky to use StringRef as map index type. Instantiating temporary toolchains is not common, but temporary strings definitely are.

llvm-project/clang/lib/Driver/Driver.cpp

Line 2570 in c979ce7

C.getArgsForToolChain(&TC, Triple.getArchName(), Action::OFK_None);

would be one. More bugs be waiting.

[Meinersbur]

@jhuber6 Do you intend to fix the dangling BoundArch as well?

[jhuber6]

@jhuber6 Do you intend to fix the dangling BoundArch as well?

Can you point that out again? AFAIK all the architectures come from a string constant in the ELF.