Fix out of bounds read in slarrv

[Keno]

This was originally reported as JuliaLang/julia#42415.
I've tracked this down to an out of bounds read on the following line:

lapack/SRC/slarrv.f

Line 423 in 44ecb6a

DO 170 JBLK = 1, IBLOCK( M )

In the crashing example, M is 0, causing slarrv to read uninitialized
memory from the work array. I believe the 0 for M is correct and indeed,
the documentation above supports that M may be zero:

lapack/SRC/slarrv.f

Lines 113 to 116 in 44ecb6a

	*> \param[in] M
	*> \verbatim
	*> M is INTEGER
	*> The total number of input eigenvalues. 0 <= M <= N.

I believe it may be sufficient to early-out this function as suggested
in this PR. However, I have limited context for the full routine here,
so I would appreciate a sanity check.

[andreasnoack]

It looks right to but it might make sense to move this check to

lapack/SRC/slarrv.f

Lines 353 to 355 in 44ecb6a

	IF( N.LE.0 ) THEN
	RETURN
	END IF

where there is already an early exit check.

This issue was found in JuliaLang/julia#42415, i.e. the original call was from sstemr and this seems to happen when requesting eigenvectors corresponding to an interval that doesn't contain any eigenvalues.

This PR only fixes the s version of xlarrv so if the fix is considered correct then similar changes should be made to the d, c, and z versions.

[codecov]

Codecov Report

Merging #625 (0631b6b) into master (44ecb6a) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #625   +/-   ##
=======================================
  Coverage    0.00%    0.00%           
=======================================
  Files        1894     1894           
  Lines      184021   184021           
=======================================
  Misses     184021   184021           

Impacted Files	Coverage Δ
SRC/clarrv.f	0.00% <0.00%> (ø)
SRC/dlarrv.f	0.00% <0.00%> (ø)
SRC/slarrv.f	0.00% <0.00%> (ø)
SRC/zlarrv.f	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 44ecb6a...0631b6b. Read the comment docs.

[martin-frbg]

Looks good to me (with the change suggested by andreasnoack, to move the exit to the start of the function where we already check for N.LE.0 )

[weslleyspereira]

I agree with @martin-frbg and @andreasnoack. Could you do this slightly modification, @Keno? Thanks a lot.

[Keno]

I updated the PR.

[weslleyspereira]

Thanks!! I've just merged it.

[langou]

Thanks @Keno. Excellent!

[thoger]

We got an info that VulnDB is flagging this fix as a security issue. The relevant VulnDB link should be:

https://vulndb.cyberriskanalytics.com/vulnerabilities/270365

and should include the following description:

OpenBLAS contains an out-of-bounds read error in the zlarrv.f library that occurs when user input is not validated properly. This could allow a remote attacker to crash the process associated with the library, or potentially expose the contents of memory by executing arbitrary code.

Note that it's flagging OpenBLAS as affected, not lapack directly, but the relevant file is the lapack code bundled in OpenBLAS.

However, this information is part of the VulnDB subscriber-only content and I do not have access to it, we only got this information indirectly.

AFAICT, there was no CVE assigned for the issue. I'd like to ask if you have any concerns with getting a CVE assigned here as the issue is already getting flagged as a vulnerability. Any thoughts on how likely this issue may be triggered in a real-world use cases via untrusted inputs to a non-malicious applications?

[Keno]

It is an out of bounds read, so it does qualify as the kind of vulnerability CVEs are issued for if someone wanted to write that up and submit it. Not sure how likely it is that someone is taking untrusted matrices and running a symmetric tridiag eigensolve on them, which is a bit of a niche thing to do, but if you are, crafting a malicious input is pretty easy.

[thoger]

Thank you! CVE-2021-4048 was assigned.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4048