Bugzilla – Bug 1193562
VUL-1: CVE-2021-4048: lapack,openblas: Out-of-bounds read in *larrv
Last modified: 2022-03-29 16:07:31 UTC
rh#2024358 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. References: https://bugzilla.redhat.com/show_bug.cgi?id=2024358 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-4048 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4048 https://vulndb.cyberriskanalytics.com/vulnerabilities/270365
Only openSUSE:Factory is affected, no SLE codestreams are vulnerable. Upstream fix: https://github.com/Reference-LAPACK/lapack/commit/38f3eeee3108b18158409ca2a100e6fe03754781
Keep open to fix TW.
Btw, the functions are inherently unsafe since the dimensions of the arrays are being passed as function arguments. If function arguments cannot be trusted then we're hosed. What the "fix" does is validate argument constraints (M >= 0) together with early out (M == 0). But if the attacker crafts M == 12375462 (large dimension) it will still crash. It's like complaining that strncpy with attacker controlled 'n' is "broken". The fix has to be on the caller side, just checking that 'n' is not < 0 is - err, short-sighted.
Fixed (accepted to science/lapack - I'm no maintainer there so cannot forward if that's not already done).
openblas is still affected by the same CVE. Fix is available with the 0.3.18 release, because of regressions with it at least 0.3.19 should be used
I'm not a maintainer of that package, re-assigning.
I have just realized that the SLE codestreams are in fact affected, so my apologies for missing that. However, as Richard mentioned, if the rationale behind these functions is that array sizes are to be trusted, then this does not seem that severe. After all, for older versions, we are lacking as well the check for the N parameter for this family of functions, and I don't think that has a CVE assigned. I have updated the CVSS score to reflect this. Anyhow, the unpatched SLE codestreams are: - SUSE:SLE-11-SP3:Update/lapack - SUSE:SLE-12:Update/lapack - SUSE:SLE-15:Update/lapack - SUSE:SLE-12-SP2:GA:Products:Update/openblas - SUSE:SLE-15:Update/openblas - SUSE:SLE-15-SP1:Update/openblas - SUSE:SLE-15-SP2:Update/openblas - SUSE:SLE-15-SP3:Update/openblas - SUSE:SLE-15-SP4:Update/openblas On openSUSE: - openSUSE:Factory/lapack - openSUSE:Factory/openblas
Yes, the attacker now just has to make sure the MSB of the passed size is not set since the "fix" is simply to rule out "negative" lengths. But an arbitrary large (non-negative) length caused by misbehaving callers will still cause the functions to crash. So yes, the change fixes an omission in lapack but it isn't really a fix - true fixes for any actual exploits will _always_ have to be to the caller! Now that this is "affecting" SLE, I'd recommend to close as INVALID. It's not a security bug in lapack which works as designed. It's a security issue in all consumers in that they are using a library with "insecure" API (whatever that means, like a programm using strcpy () instead of strncpy () isn't a security issue in glibc but in the caller).
(In reply to Richard Biener from comment #8) > Yes, the attacker now just has to make sure the MSB of the passed size is > not set since the "fix" is simply to rule out "negative" lengths. But an > arbitrary large (non-negative) length caused by misbehaving callers will > still cause the functions to crash. > > So yes, the change fixes an omission in lapack but it isn't really a fix - > true fixes for any actual exploits will _always_ have to be to the caller! In particular the check is an optimization and the return value is not adjusted to indicate an error. > Now that this is "affecting" SLE, I'd recommend to close as INVALID. It's > not a security bug in lapack which works as designed. It's a security issue > in all consumers in that they are using a library with "insecure" API > (whatever that means, like a programm using strcpy () instead of strncpy () > isn't a security > issue in glibc but in the caller).
(In reply to Richard Biener from comment #8) > Yes, the attacker now just has to make sure the MSB of the passed size is > not set since the "fix" is simply to rule out "negative" lengths. But an > arbitrary large (non-negative) length caused by misbehaving callers will > still cause the functions to crash. > > So yes, the change fixes an omission in lapack but it isn't really a fix - > true fixes for any actual exploits will _always_ have to be to the caller! It seems that the main issue here is the case where M = 0, although the patch also addresses negative lengths. As the reporter points out, M = 0 should be a valid value, according to the documentation: https://github.com/Reference-LAPACK/lapack/pull/625 https://github.com/Reference-LAPACK/lapack/blob/44ecb6a5ff821b1cbb39f8cc2166cb098e060b4d/SRC/slarrv.f#L113-L116
lapack is not ours.
@Carlos: I've created bsc#1196513 now. Please make adjustments needed by the security team.
(In reply to Richard Biener from comment #8) > Yes, the attacker now just has to make sure the MSB of the passed size is > not set since the "fix" is simply to rule out "negative" lengths. But an > arbitrary large (non-negative) length caused by misbehaving callers will > still cause the functions to crash. > > So yes, the change fixes an omission in lapack but it isn't really a fix - > true fixes for any actual exploits will _always_ have to be to the caller! > > Now that this is "affecting" SLE, I'd recommend to close as INVALID. It's > not a security bug in lapack which works as designed. It's a security issue > in all consumers in that they are using a library with "insecure" API > (whatever that means, like a programm using strcpy () instead of strncpy () > isn't a security > issue in glibc but in the caller). Unfortunately, it is easy to mark any nonsense as a security bug to get attention and take a CVE home as a trophy. I expect to see many more such issues on openblas - as we have been seeing for hdf5. While I can see a point that hdf5 should be more robust against malformed input data, the LAPACK issue is really out of line. But to avoid any arguments and since the fix was sufficiently easy to port, I've fixed this for openblas.
So mine again for lapack and the SLE codestreams.
(In reply to Richard Biener from comment #14) > So mine again for lapack and the SLE codestreams. The codestream shipped in SLE12 and SLE15 is based on lapack 3.5.0 which doesn't even check for N <= 0. It also never sets INFO to zero so it seems the error behavior is sticky, similar to libc errno, in that codestream. To make the CVE gods happy I'll cut&paste the early return to the relevant functions but will not change INFO handling. But as said, I'd rather leave the SLE codestreams alone. SRs coming.
Fixed.
Hi Richard, please do not close security-related BZ issues instead re-assign them back to the security-team.
openSUSE-SU-2022:0915-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 1193562 CVE References: CVE-2021-4048 JIRA References: Sources used: openSUSE Leap 15.4 (src): lapack-3.5.0-4.6.1, lapack-man-3.5.0-4.6.1 openSUSE Leap 15.3 (src): lapack-3.5.0-4.6.1, lapack-man-3.5.0-4.6.1
SUSE-SU-2022:0915-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 1193562 CVE References: CVE-2021-4048 JIRA References: Sources used: SUSE Linux Enterprise Realtime Extension 15-SP2 (src): lapack-3.5.0-4.6.1 SUSE Linux Enterprise Module for Development Tools 15-SP3 (src): lapack-3.5.0-4.6.1 SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): lapack-3.5.0-4.6.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:0913-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 1193562 CVE References: CVE-2021-4048 JIRA References: Sources used: SUSE Linux Enterprise Software Development Kit 12-SP5 (src): lapack-3.5.0-3.9.1 SUSE Linux Enterprise Server 12-SP5 (src): lapack-3.5.0-3.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Back to security for closing (SLE11 still to be released it seems).
(In reply to Egbert Eich from comment #13) > (In reply to Richard Biener from comment #8) > > Yes, the attacker now just has to make sure the MSB of the passed size is > > not set since the "fix" is simply to rule out "negative" lengths. But an > > arbitrary large (non-negative) length caused by misbehaving callers will > > still cause the functions to crash. > > > > So yes, the change fixes an omission in lapack but it isn't really a fix - > > true fixes for any actual exploits will _always_ have to be to the caller! > > > > Now that this is "affecting" SLE, I'd recommend to close as INVALID. It's > > not a security bug in lapack which works as designed. It's a security issue > > in all consumers in that they are using a library with "insecure" API > > (whatever that means, like a programm using strcpy () instead of strncpy () > > isn't a security > > issue in glibc but in the caller). > > Unfortunately, it is easy to mark any nonsense as a security bug to get > attention and take a CVE home as a trophy. > I expect to see many more such issues on openblas - as we have been seeing > for hdf5. While I can see a point that hdf5 should be more robust against > malformed input data, the LAPACK issue is really out of line. > But to avoid any arguments and since the fix was sufficiently easy to port, > I've fixed this for openblas. Hi Egbert, thanks for your input. Anyway I don't see the submissions for openblas. Have you mentioned bsc and cve IDs in the changes files?