Another segfault

[sp1ritCS]

The equation

$=\text{Ker}\begin{pmatrix}{\tiny \begin{matrix}\lambda_1-\lambda_i\\&\lambda_1-\lambda_i\end{matrix}}\\&{\tiny \begin{matrix}\ddots\\&0\\&&0\\&&&0\\&&&&0\end{matrix}\\&&{\tiny \begin{matrix}\lambda_1-\lambda_i\\&\lambda_1-\lambda_i\end{matrix}}}$

causes MicroTeX to segfault. While this isn't valid TeX and should probably result in a parsing failure, it shouldn't cause whatever application links against MicroTeX to crash.

(Also occurs on clm)

I've tried fixing it, however the entire stack seems to be exlusively random garbage in gdb

[NanoMichael]

fixed by 97e4b5d.

See this example.

On XeLaTeX and LuaLaTeX, this code will result in an error. The best approach would be to inform the user that using it this way is incorrect, but for now let's leave it as is.

By the way, the following code can achieve the effect you desire:

$=\text{Ker}
\tiny
\begin{pmatrix}
  \lambda_1-\lambda_i\\
  &\lambda_1-\lambda_i\\
  &&\ddots\\
  &&&0\\
  &&&&0\\
  &&&&&0\\
  &&&&&&0\\
  &&&&&&&\lambda_1-\lambda_i\\
  &&&&&&&&\lambda_1-\lambda_1
\end{pmatrix}
$

[sp1ritCS]

fixed by 97e4b5d .

great. I think I had already found a working version that used matrices within the matrix (useful when you want to "box" a certain part of the matrix using \fbox.

But the most important thing about this was that the stack-smashing that happened won't occur anymore (at least in this case), given that with specifically crafted formula input you're likely to get arbitrary code execution, which seems really dangerous. Maybe one should look into fuzzing to check if there is more of that.

[NanoMichael]

given that with specifically crafted formula input you're likely to get arbitrary code execution, which seems really dangerous

That's true. But currently it seems that this situation is still within a controllable range, so I don't think we need to worry too much about it right now.

[sp1ritCS]

But currently it seems that this situation is still within a controllable range, so I don't think we need to worry too much about it right now.

I'm not actually sure it is 🙃 . On the one hand, I'm don't think anyone is currently rendering "untrusted" equations using clm/µTeX, however if someone were to do that, it'll likely be quite fatal.

However, a very large majority of crashes logged by notekit are due to cLaTeXMath. Obv. a large chunk of them already shouldn't occur anymore once MicroTeX is released, as the most common segfaults are already fixed, but running a fuzzer over it (~sp1ritCS:cLaTeXMath/fuzzer) I found 600 (filtered to 100) crashes in a very short amount of time, so I'll look into fixing at least some of them.

[NanoMichael]

But currently it seems that this situation is still within a controllable range, so I don't think we need to worry too much about it right now.

I'm not actually sure it is upside_down_face . On the one hand, I'm don't think anyone is currently rendering "untrusted" equations using clm/µTeX, however if someone were to do that, it'll likely be quite fatal.

However, a very large majority of crashes logged by notekit are due to cLaTeXMath. Obv. a large chunk of them already shouldn't occur anymore once MicroTeX is released, as the most common segfaults are already fixed, but running a fuzzer over it (~sp1ritCS:cLaTeXMath/fuzzer) I found 600 (filtered to 100) crashes in a very short amount of time, so I'll look into fixing at least some of them.

Wow, that's something I wasn't aware of... Are you willing to submit the fuzzer test code to the openmath branch? I'd like to test it out as well.

[sp1ritCS]

Are you willing to submit the fuzzer test code to the openmath branch? I'd like to test it out as well.

sure, I'll look into submitting it tomorrow :). I'd be great if you could look into adding it to the cmake, as it currently only "supports" meson. It's mostly about detecting if the current compiler is afl-cc/afl-c++ and if so, enable building of the fuzzer.cpp + platform_none.cpp. If you want to test it now from my tree, you'd have to invoke meson setup <buildir> --cross-file test/fuzzer/afl.cross, then navigate to test/fuzzer (not quite sure but probably create seed/ and output/ dirs) run ./generateSeed.java and then fuzzing should work with ./fuzz.sh (but you may want to remove AFL_SKIP_CPUFREQ=1 from it)

I also have already like five small nullptr deref fixes on my machine, I'll look into submitting them to

[sp1ritCS]

closing this as it has been fixed