FYI: CVEs

[loveshack]

In case you don't know, CVEs have been raised against libxsmm_gemm_generator again, at least CVE-2021-39535 ("NULL pointer dereference exists in JIT code", "Denial of Service") and CVE-2021-39536 ("JIT code has a heap-based buffer overflow") from the notification spam I've had from Fedora.
Unfortunately if you dismiss such things you get called highly irresponsible.

[hfp]

@loveshack Thank you, Dave!

I will take a look asap.

[loveshack]

I should have been explicit that there's nothing to do unless, perhaps, CVEs can be invalidated. I thought it was worth noting as it looked as if no-one had informed the project they'd been raised. There's already a change in the development source, and clearly it's not a security issue if a fairly obscure development tool crashes, any more than when GCC SEGVs. Last time, the people complaining about ignoring CVEs weren't prepared to check what the flaw actually was.

[hfp]

The CVEs are both fixed since August 2020 (~time when issues were reported). However, we made no release since then which is including the fixes. I will check if 1.16.3 is feasible with just these fixes.

[loveshack]

Yes, it was clear they're fixed. I wouldn't bother with a new release. It's no more a possible denial of service than for #287 is it?

[hfp]

Issue #287 was a different flow like filing CVEs without ever talking to us just for the sake of claiming something for publication (somewhat blaming this project). I consider the #398 and #402 absolutely valid claims including the reporting flow. Though, libxsmm_gemm_generator is a legacy tool which is kept for compatibility with some applications (they know how to not pass invalid input). However, ASAN (or similar tools) used to check upstreamed bits make a valid case worth to get our attention.

[hfp]

Let me close your report since v1.16.3 was published to address the two CVEs. Thank you again for raising attention for the upstream work and process!