[mlir] mlir::outlineSingleBlockRegion crashes with segmentation fault.

[Colloportus0]

MLIR built at commit a0dab4950
Reproduced with:

mlir-opt --test-scf-if-utils temp.mlir

temp.mlir:

func.func @func(
  %arg0: index,
  %arg1: index,
  %arg2: index,
  %arg3: memref<2xf32>) -> memref<2xf32> {
  %0 = memref.alloc() : memref<2xf32>
  %1 = scf.for %i = %arg0 to %arg1 step %arg2
    iter_args(%arg4 = %arg3) -> memref<2xf32> {
    %2 = arith.cmpi eq, %i, %arg1 : index
    %3 = scf.if %2 -> (memref<2xf32>) { 
      scf.yield %0 : memref<2xf32>
    } else {
      scf.yield %0 : memref<2xf32>
    }
    scf.yield %0 : memref<2xf32>
  }
  return %1 : memref<2xf32>
}

trace:

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: mlir-opt --test-scf-if-utils temp.mlir
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  mlir-opt                 0x00000001041b86b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  mlir-opt                 0x00000001041b7720 llvm::sys::RunSignalHandlers() + 112
2  mlir-opt                 0x00000001041b8d50 SignalHandler(int) + 344
3  libsystem_platform.dylib 0x00000001aad414c4 _sigtramp + 56
4  mlir-opt                 0x0000000104d025fc mlir::outlineSingleBlockRegion(mlir::RewriterBase&, mlir::Location, mlir::Region&, llvm::StringRef, mlir::func::CallOp*) + 256
5  mlir-opt                 0x0000000104d03330 mlir::outlineIfOp(mlir::RewriterBase&, mlir::scf::IfOp, mlir::func::FuncOp*, llvm::StringRef, mlir::func::FuncOp*, llvm::StringRef) + 160
6  mlir-opt                 0x000000010558a830 mlir::WalkResult llvm::function_ref<mlir::WalkResult (mlir::Operation*)>::callback_fn<std::__1::enable_if<!llvm::is_one_of<mlir::scf::IfOp, mlir::Operation*, mlir::Region*, mlir::Block*>::value && std::is_same<mlir::WalkResult, mlir::WalkResult>::value, mlir::WalkResult>::type mlir::detail::walk<(mlir::WalkOrder)1, (anonymous namespace)::TestSCFIfUtilsPass::runOnOperation()::'lambda'(mlir::scf::IfOp), mlir::scf::IfOp, mlir::WalkResult>(mlir::Operation*, (anonymous namespace)::TestSCFIfUtilsPass::runOnOperation()::'lambda'(mlir::scf::IfOp)&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) + 404
7  mlir-opt                 0x0000000105959838 mlir::detail::walk(mlir::Operation*, llvm::function_ref<mlir::WalkResult (mlir::Operation*)>, mlir::WalkOrder) + 160
8  mlir-opt                 0x0000000105959838 mlir::detail::walk(mlir::Operation*, llvm::function_ref<mlir::WalkResult (mlir::Operation*)>, mlir::WalkOrder) + 160
9  mlir-opt                 0x0000000105959838 mlir::detail::walk(mlir::Operation*, llvm::function_ref<mlir::WalkResult (mlir::Operation*)>, mlir::WalkOrder) + 160
10 mlir-opt                 0x000000010558a53c (anonymous namespace)::TestSCFIfUtilsPass::runOnOperation() + 112
11 mlir-opt                 0x0000000105834428 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) + 428
12 mlir-opt                 0x0000000105834958 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) + 320
13 mlir-opt                 0x00000001058362d4 mlir::PassManager::run(mlir::Operation*) + 1148
14 mlir-opt                 0x000000010582f698 performActions(llvm::raw_ostream&, bool, bool, std::__1::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, llvm::function_ref<mlir::LogicalResult (mlir::PassManager&)>, bool, bool) + 504
15 mlir-opt                 0x000000010582f268 mlir::LogicalResult llvm::function_ref<mlir::LogicalResult (std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<mlir::LogicalResult (mlir::PassManager&)>, mlir::DialectRegistry&, bool, bool, bool, bool, bool, bool, bool)::$_0>(long, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) + 704
16 mlir-opt                 0x0000000105899f5c mlir::splitAndProcessBuffer(std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<mlir::LogicalResult (std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, bool, bool) + 656
17 mlir-opt                 0x000000010582d690 mlir::MlirOptMain(llvm::raw_ostream&, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<mlir::LogicalResult (mlir::PassManager&)>, mlir::DialectRegistry&, bool, bool, bool, bool, bool, bool, bool) + 216
18 mlir-opt                 0x000000010582db84 mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&, bool) + 1208
19 mlir-opt                 0x000000010405aae4 main + 108
20 dyld                     0x000000010918d088 start + 516

[llvmbot]

@llvm/issue-subscribers-mlir

[siddhesh]

This inexplicably got assigned a CVE-2023-26924, which I assume will be rejected given LLVM's security process?

[ajakk]

This inexplicably got assigned a CVE-2023-26924, which I assume will be rejected given LLVM's security process?

Why would it be automatically rejected? MITRE doesn't care, they assign CVEs from anyone with very little validation.

[ajakk]

I've requested that MITRE reject the CVE based on https://llvm.org/docs/Security.html#what-is-considered-a-security-issue.

[siddhesh]

This inexplicably got assigned a CVE-2023-26924, which I assume will be rejected given LLVM's security process?

Why would it be automatically rejected? MITRE doesn't care, they assign CVEs from anyone with very little validation.

Sorry, I meant to ask if the LLVM project will be filing a rejection, thanks for doing that. I could do it downstream (for Fedora/RHEL) but it's usually just easy if upstream does it. However I understand it's not scalable to do a formal filing for all reports; as downstream I'm happy with just a comment on the issue rejecting the security impact. Thanks!

[rikhuijzer]

Anyone else able to reproduce this? I'm unable to reproduce on a0dab4950 or main:

$ cd ~/git/llvm-project/

$ cmake -G Ninja llvm \
        -DLLVM_ENABLE_PROJECTS=mlir \
        -DLLVM_BUILD_EXAMPLES=OFF \
        -DLLVM_TARGETS_TO_BUILD="Native" \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_ASSERTIONS=ON
[...]

$ cmake --build .
[...]

$ bin/mlir-opt temp.mlir --test-scf-if-utils
module {
  func.func @outlined_then0(%arg0: memref<2xf32>) -> memref<2xf32> {
    return %arg0 : memref<2xf32>
  }
  func.func @outlined_else0(%arg0: memref<2xf32>) -> memref<2xf32> {
    return %arg0 : memref<2xf32>
  }
  func.func @func(%arg0: index, %arg1: index, %arg2: index, %arg3: memref<2xf32>) -> memref<2xf32> {
    %alloc = memref.alloc() : memref<2xf32>
    %0 = scf.for %arg4 = %arg0 to %arg1 step %arg2 iter_args(%arg5 = %arg3) -> (memref<2xf32>) {
      %1 = arith.cmpi eq, %arg4, %arg1 : index
      %2 = scf.if %1 -> (memref<2xf32>) {
        %3 = func.call @outlined_then0(%alloc) : (memref<2xf32>) -> memref<2xf32>
        scf.yield %3 : memref<2xf32>
      } else {
        %3 = func.call @outlined_else0(%alloc) : (memref<2xf32>) -> memref<2xf32>
        scf.yield %3 : memref<2xf32>
      }
      scf.yield %alloc : memref<2xf32>
    }
    return %0 : memref<2xf32>
  }
}

[ajakk]

I've requested that MITRE reject the CVE based on https://llvm.org/docs/Security.html#what-is-considered-a-security-issue.

FTR, this was MITRE's response:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thank you for sending this. CVE-2023-26924 may well be invalid if it
is simply reporting that the mlir-opt program will crash with a
segmentation fault (and it is not potentially exploitable for code
execution).

A security policy of "a maliciously crafted C or Rust source file can
cause arbitrary code to execute in LLVM" is a different situation, and
there is a (maybe very small) number of CVE consumers who will stop
using LLVM on a subset of their build machines once this policy is
known to them.

- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJkTcoPAAoJENiPHH3233OGuygP/RHJu5xYXQ+W5dCqcuFXA1Pg
wBvfToYMMgLktSCILdGa2/kAiFUO6JetlP9g191Fhx0jFMaKaVWc9DZwV+nImG+k
plFYHmI2ZZt1rAKeV94Is7LeZ5hO/pXgRs4trkWjZt/8jQCb4NQQNyVvQv7so7OX
L+hwFY1ZIdjbrJ7nK6T//DqjrY3x7cHTLKpRh3D/ENyc++cRytRkAOTFlACgs8av
9vicJszB5S3FDnPLf52MTzx7YE1tMC3D7CmMghsExM8u8Y11/Ljz+EzQq/keQRVe
A+72P96kKPZfkgX9ckFmlPuKPNluKm9r7hfPBACp4+/G0fxjeVg5/LyGLyoMGHBe
F4LWJb6Gtbd+mo6Y3x8SdbDdZ18RFERcR1nX5fZLSLT/z/Tl4hy9l6E0H+rALv4e
5JiD1U4ss4l2ukO0NkQcYMdPzxxgFo34mQ2UaSZTWPtX1yfCtFqQx0BzgfGPEdtx
FMMewav9Aa8VjbhbqIEWTip4dUVS9TodW6GP0CNtviL60rgW+gF+9BXt0U3m8Mql
YLE3n4p6kgbu63vbKCo084w5dO2gLzGk6NX0r8+hRq2DwyUVpTfOBgbujW9v6oue
Va+xFtslsDbKrporlrJCnJWjRo/36CNkPlEJpJeAqSQspIxa+viR72keNUtTOfLo
cd0uZS/Z8jEzROwkOA2U
=Ee62
-----END PGP SIGNATURE-----

[joker-eph]

NOTE: third parties dispute this because the LLVM security policy excludes "Language front-ends ... for which a malicious input file can cause undesirable behavior."

This is even not really relevant, here we have what seems to be fuzzed that are directed at entry point which are meant to just be exposed to unit-tests. None of the -test-* passes are even shipped in the MLIR libraries themselves: so this is all about the testing environment.

[marcus-schmidt]

Hi to everyone who has thankfully dealt with this problem. I was wondering whether there has been any news on the rejection request? Apparently the CVE is still open, and third-party security scanning tools have started reporting the affected LLVM version.

From what I understood so far, there are several reasons for rejecting this as a security vulnerability:

• There is no evidence for an arbitrary code execution vulnerability
• The problem appears only in test code
• It is unclear if the segfault even reproduces

Based on this argumentation, would it be possible to get the CVE closed? I am also happy to help if there is something I am able to do.

[siddhesh]

Unfortunately Mitre hasn't been very discerning (or even responsive to disputes) and the trend of spurious CVE assignments continues; there are (AFAICT) at least 6 more bugs in MLIR that have got CVE numbers without any real reasoning.