MontaVista CVE List and Response

MontaVista continually monitors the security community and customers for threats. We follow the community on CVE scoring (NVD) and set fix priority accordingly for affected products. Please view the following CVEs that have been remediated or are in process by clicking the CVE Year to the left or use the CVE Filters below.

For inquiries regarding Security Vulnerabilities, please see our Vulnerability Response Policy or email our PSIRT team security@mvista.com. Email messages and attachments can be encrypted using PGP and a MontaVista PSIRT PGP key, which is available for download here.

Year
Product
Score
Severity
Status
CVE
CVE Score Severity Package Description Published
CVE-2024-27351
7.5 (i)
Centos 7.9 Under Investigation
HIGHdjango In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665. 2024-03-15
CVE-2024-2193
5.5 (i)
CGX 3.1 Under Investigation
Centos 7.9 Under Investigation
Centos 7.9 Under Investigation
Centos 7.9 Under Investigation
CGX 4.0 Under Investigation
Rocky 9.3 Under Investigation
Rocky 8.9 Under Investigation
MEDIUMkernel A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. 2024-03-15
CVE-2023-6725
7.8 (i)
Centos 7.9 Under Investigation
HIGHdesignate An access-control flaw was found in the OpenStack Designate component where private configuration information including access keys to BIND were improperly made world readable. A malicious attacker with access to any container could exploit this flaw to access sensitive information. 2024-03-15
CVE-2024-26630
7.1 (i)
Centos 7.9 Not Affected
Rocky 9.3 Under Investigation
CGX 3.1 Wont Fix
CGX 4.0 Not Affected
Centos 7.9 Not Affected
Centos 7.9 Under Investigation
Rocky 8.9 Under Investigation
HIGHkernel In the Linux kernel, the following vulnerability has been resolved:mm: cachestat: fix folio read-after-free in cache walkIn cachestat, we access the folio from the page cache's xarray to computeits page offset, and check for its dirty and writeback flags. However, wedo not hold a reference to the folio before performing these actions,which means the folio can concurrently be released and reused as anotherfolio/page/slab.Get around this altogether by just using xarray's existing machinery forthe folio page offsets and dirty/writeback states.This changes behavior for tmpfs files to now always report zeroes in theirdirty and writeback counters. This is okay as tmpfs doesn't followconventional writeback cache behavior: its pages get "cleaned" duringswapout, after which they're no longer resident etc. 2024-03-13
CVE-2024-26629
5.5 (i)
CGX 4.0 Under Investigation
CGX 3.1 Under Investigation
Centos 7.9 Under Investigation
Rocky 9.3 Under Investigation
Rocky 8.9 Under Investigation
Centos 7.9 Under Investigation
Centos 7.9 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:nfsd: fix RELEASE_LOCKOWNERThe test on so_count in nfsd4_release_lockowner() is nonsense andharmful. Revert to using check_for_locks(), changing that to not sleep.First: harmful.As is documented in the kdoc comment for nfsd4_release_lockowner(), thetest on so_count can transiently return a false positive resulting in areturn of NFS4ERR_LOCKS_HELD when in fact no locks are held. This isclearly a protocol violation and with the Linux NFS client it can causeincorrect behaviour.If RELEASE_LOCKOWNER is sent while some other thread is stillprocessing a LOCK request which failed because, at the time that requestwas received, the given owner held a conflicting lock, then the nfsdthread processing that LOCK request can hold a reference (conflock) tothe lock owner that causes nfsd4_release_lockowner() to return anincorrect error.The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because itnever sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, soit knows that the error is impossible. It assumes the lock owner was infact released so it feels free to use the same lock owner identifier insome later locking request.When it does reuse a lock owner identifier for which a previous RELEASEfailed, it will naturally use a lock_seqid of zero. However the server,which didn't release the lock owner, will expect a larger lock_seqid andso will respond with NFS4ERR_BAD_SEQID.So clearly it is harmful to allow a false positive, which testingso_count allows.The test is nonsense because ... well... it doesn't mean anything.so_count is the sum of three different counts.1/ the set of states listed on so_stateids2/ the set of active vfs locks owned by any of those states3/ various transient counts such as for conflicting locks.When it is tested against '2' it is clear that one of these is thetransient reference obtained by find_lockowner_str_locked(). It is notclear what the other one is expected to be.In practice, the count is often 2 because there is precisely one stateon so_stateids. If there were more, this would fail.In my testing I see two circumstances when RELEASE_LOCKOWNER is called.In one case, CLOSE is called before RELEASE_LOCKOWNER. That results inall the lock states being removed, and so the lockowner being discarded(it is removed when there are no more references which usually happenswhen the lock state is discarded). When nfsd4_release_lockowner() findsthat the lock owner doesn't exist, it returns success.The other case shows an so_count of '2' and precisely one state listedin so_stateid. It appears that the Linux client uses a separate lockowner for each file resulting in one lock state per lock owner, so thistest on '2' is safe. For another client it might not be safe.So this patch changes check_for_locks() to use the (newish)find_any_file_locked() so that it doesn't take a reference on thenfs4_file and so never calls nfsd_file_put(), and so never sleeps. Withthis check is it safe to restore the use of check_for_locks() ratherthan testing so_count against the mysterious '2'. 2024-03-13
CVE-2023-52608
4.4 (i)
Centos 7.9 Not Affected
Centos 7.9 Not Affected
CGX 3.1 Not Affected
CGX 4.0 Under Investigation
Rocky 9.3 Not Affected
Rocky 8.9 Not Affected
Centos 7.9 Not Affected
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Check mailbox/SMT channel for consistencyOn reception of a completion interrupt the shared memory area is accessedto retrieve the message header at first and then, if the message sequencenumber identifies a transaction which is still pending, the relatedpayload is fetched too.When an SCMI command times out the channel ownership remains with theplatform until eventually a late reply is received and, as a consequence,any further transmission attempt remains pending, waiting for the channelto be relinquished by the platform.Once that late reply is received the channel ownership is given backto the agent and any pending request is then allowed to proceed andoverwrite the SMT area of the just delivered late reply; then the waitfor the reply to the new request starts.It has been observed that the spurious IRQ related to the late reply canbe wrongly associated with the freshly enqueued request: when that happensthe SCMI stack in-flight lookup procedure is fooled by the fact that themessage header now present in the SMT area is related to the new pendingtransaction, even though the real reply has still to arrive.This race-condition on the A2P channel can be detected by looking at thechannel status bits: a genuine reply from the platform will have set thechannel free bit before triggering the completion IRQ.Add a consistency check to validate such condition in the A2P ISR. 2024-03-13
CVE-2024-26620
5.5 (i)
Centos 7.9 Not Affected
CGX 4.0 Wont Fix
Centos 7.9 Not Affected
Rocky 9.3 Not Affected
CGX 3.1 Wont Fix
Rocky 8.9 Not Affected
Centos 7.9 Not Affected
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:s390/vfio-ap: always filter entire AP matrixThe vfio_ap_mdev_filter_matrix function is called whenever a new adapter ordomain is assigned to the mdev. The purpose of the function is to updatethe guest's AP configuration by filtering the matrix of adapters anddomains assigned to the mdev. When an adapter or domain is assigned, onlythe APQNs associated with the APID of the new adapter or APQI of the newdomain are inspected. If an APQN does not reference a queue device bound tothe vfio_ap device driver, then it's APID will be filtered from the mdev'smatrix when updating the guest's AP configuration.Inspecting only the APID of the new adapter or APQI of the new domain willresult in passing AP queues through to a guest that are not bound to thevfio_ap device driver under certain circumstances. Consider the following:guest's AP configuration (all also assigned to the mdev's matrix):14.000414.000514.000616.000416.000516.0006unassign domain 4unbind queue 16.0005assign domain 4When domain 4 is re-assigned, since only domain 4 will be inspected, theAPQNs that will be examined will be:14.000416.0004Since both of those APQNs reference queue devices that are bound to thevfio_ap device driver, nothing will get filtered from the mdev's matrixwhen updating the guest's AP configuration. Consequently, queue 16.0005will get passed through despite not being bound to the driver. Thisviolates the linux device model requirement that a guest shall only begiven access to devices bound to the device driver facilitating theirpass-through.To resolve this problem, every adapter and domain assigned to the mdev willbe inspected when filtering the mdev's matrix. 2024-03-11
CVE-2024-26619
5.5 (i)
Centos 7.9 Not Affected
Rocky 8.9 Not Affected
Centos 7.9 Not Affected
CGX 4.0 Wont Fix
Centos 7.9 Not Affected
CGX 3.1 Wont Fix
Rocky 9.3 Not Affected
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:riscv: Fix module loading free orderReverse order of kfree calls to resolve use-after-free error. 2024-03-11
CVE-2024-26618
5.5 (i)
Centos 7.9 Not Affected
CGX 4.0 Wont Fix
CGX 3.1 Wont Fix
Rocky 8.9 Under Investigation
Centos 7.9 Not Affected
Centos 7.9 Not Affected
Rocky 9.3 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:arm64/sme: Always exit sme_alloc() early with existing storageWhen sme_alloc() is called with existing storage and we are not flushing wewill always allocate new storage, both leaking the existing storage andcorrupting the state. Fix this by separating the checks for flushing andfor existing storage as we do for SVE.Callers that reallocate (eg, due to changing the vector length) shouldcall sme_free() themselves. 2024-03-11
CVE-2024-26617
5.5 (i)
Centos 7.9 Not Affected
Rocky 8.9 Under Investigation
Centos 7.9 Not Affected
Rocky 9.3 Under Investigation
CGX 4.0 Wont Fix
Centos 7.9 Not Affected
CGX 3.1 Wont Fix
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:fs/proc/task_mmu: move mmu notification mechanism inside mm lockMove mmu notification mechanism inside mm lock to prevent race conditionin other components which depend on it. The notifier will invalidatememory range. Depending upon the number of iterations, different memoryranges would be invalidated.The following warning would be removed by this patch:WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734There is no behavioural and performance change with this patch whenthere is no component registered with the mmu notifier.[akpm@linux-foundation.org: narrow the scope of `range', per Sean] 2024-03-11