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-26599
6.2 (i)
Centos 7.9 Not Affected
Rocky 9.3 Under Investigation
Rocky 8.9 Not Affected
CGX 4.0 Not Affected
CGX 3.1 Not Affected
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:pwm: Fix out-of-bounds access in of_pwm_single_xlate()With args->args_count == 2 args->args[2] is not defined. Actually theflags are contained in args->args[1]. 2024-02-23
CVE-2024-26598
7.8 (i)
CGX 4.0 Under Investigation
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
HIGHkernel In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cacheThere is a potential UAF scenario in the case of an LPI translationcache hit racing with an operation that invalidates the cache, suchas a DISCARD ITS command. The root of the problem is thatvgic_its_check_cache() does not elevate the refcount on the vgic_irqbefore dropping the lock that serializes refcount changes.Have vgic_its_check_cache() raise the refcount on the returned vgic_irqand add the corresponding decrement after queueing the interrupt. 2024-02-23
CVE-2024-26597
5.5 (i)
CGX 4.0 Under Investigation
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:net: qualcomm: rmnet: fix global oob in rmnet_policyThe variable rmnet_link_ops assign a *bigger* maxtype which leads to aglobal out-of-bounds read when parsing the netlink attributes. See bugtrace below:==================================================================BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fdcf2072359Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK>The buggy address belongs to the variable: rmnet_policy+0x30/0xe0The buggy address belongs to the physical page:page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243flags: 0x200000000001000(reserved|node=0|zone=2)raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9According to the comment of `nla_parse_nested_deprecated`, the maxtypeshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here. 2024-02-23
CVE-2024-26595
5.5 (i)
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 3.1 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error pathWhen calling mlxsw_sp_acl_tcam_region_destroy() from an error path afterfailing to attach the region to an ACL group, we hit a NULL pointerdereference upon 'region->group->tcam' [1].Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0[...]Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b 2024-02-23
CVE-2023-52464
7.5 (i)
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
HIGHkernel In the Linux kernel, the following vulnerability has been resolved:EDAC/thunderx: Fix possible out-of-bounds string accessEnabling -Wstringop-overflow globally exposes a warning for a common bugin the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ...Apparently the author of this driver expected strncat() to behave theway that strlcat() does, which uses the size of the destination bufferas its third argument rather than the length of the source buffer. Theresult is that there is no check on the size of the allocated buffer.Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] 2024-02-23
CVE-2023-52463
4.4 (i)
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:efivarfs: force RO when remounting if SetVariable is not supportedIf SetVariable at runtime is not supported by the firmware we never assigna callback for that function. At the same time mount the efivarfs asRO so no one can call that. However, we never check the permission flagswhen someone remounts the filesystem as RW. As a result this leads to acrash looking like this:$ mount -o remount,rw /sys/firmware/efi/efivars$ efi-updatevar -f PK.auth PK[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 303.280482] Mem abort info:[ 303.280854] ESR = 0x0000000086000004[ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits[ 303.282016] SET = 0, FnV = 0[ 303.282414] EA = 0, S1PTW = 0[ 303.282821] FSC = 0x04: level 0 translation fault[ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000[ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP[ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6[ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1[ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023[ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 303.292123] pc : 0x0[ 303.292443] lr : efivar_set_variable_locked+0x74/0xec[ 303.293156] sp : ffff800008673c10[ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000[ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027[ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000[ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000[ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54[ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4[ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002[ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201[ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc[ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000[ 303.303341] Call trace:[ 303.303679] 0x0[ 303.303938] efivar_entry_set_get_size+0x98/0x16c[ 303.304585] efivarfs_file_write+0xd0/0x1a4[ 303.305148] vfs_write+0xc4/0x2e4[ 303.305601] ksys_write+0x70/0x104[ 303.306073] __arm64_sys_write+0x1c/0x28[ 303.306622] invoke_syscall+0x48/0x114[ 303.307156] el0_svc_common.constprop.0+0x44/0xec[ 303.307803] do_el0_svc+0x38/0x98[ 303.308268] el0_svc+0x2c/0x84[ 303.308702] el0t_64_sync_handler+0xf4/0x120[ 303.309293] el0t_64_sync+0x190/0x194[ 303.309794] Code: ???????? ???????? ???????? ???????? (????????)[ 303.310612] ---[ end trace 0000000000000000 ]---Fix this by adding a .reconfigure() function to the fs operations whichwe can use to check the requested flags and deny anything that's not ROif the firmware doesn't implement SetVariable at runtime. 2024-02-23
CVE-2023-52457
7.8 (i)
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
HIGHkernel In the Linux kernel, the following vulnerability has been resolved:serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failedReturning an error code from .remove() makes the driver core emit thelittle helpful error message: remove callback returned a non-zero value. This will be ignored.and then remove the device anyhow. So all resources that were not freedare leaked in this case. Skipping serial8250_unregister_port() has thepotential to keep enough of the UART around to trigger a use-after-free.So replace the error return (and with it the little helpful errormessage) by a more useful error message and continue to cleanup. 2024-02-23
CVE-2023-52456
4.0 (i)
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:serial: imx: fix tx statemachine deadlockWhen using the serial port as RS485 port, the tx statemachine is used tocontrol the RTS pin to drive the RS485 transceiver TX_EN pin. When theTTY port is closed in the middle of a transmission (for instance duringuserland application crash), imx_uart_shutdown disables the interfaceand disables the Transmission Complete interrupt. afer that,imx_uart_stop_tx bails on an incomplete transmission, to be retriggeredby the TC interrupt. This interrupt is disabled and therefore the txstatemachine never transitions out of SEND. The statemachine is indeadlock now, and the TX_EN remains low, making the interface useless.imx_uart_stop_tx now checks for incomplete transmission AND whether TCinterrupts are enabled before bailing to be retriggered. This makes surethe state machine handling is reached, and is properly set toWAIT_AFTER_SEND. 2024-02-23
CVE-2024-26593
5.5 (i)
CGX 4.0 Under Investigation
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
Centos 7.9 Under Investigation
CGX 3.1 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:i2c: i801: Fix block process call transactionsAccording to the Intel datasheets, software must reset the blockbuffer index twice for block process call transactions: once beforewriting the outgoing data to the buffer, and once again beforereading the incoming data from the buffer.The driver is currently missing the second reset, causing the wrongportion of the block buffer to be read. 2024-02-23
CVE-2024-26586
6.7 (i)
CGX 3.1 Under Investigation
Rocky 8.9 Under Investigation
Rocky 9.3 Under Investigation
CGX 4.0 Under Investigation
Centos 7.9 Under Investigation
MEDIUMkernel In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix stack corruptionWhen tc filters are first added to a net device, the corresponding localport gets bound to an ACL group in the device. The group contains a listof ACLs. In turn, each ACL points to a different TCAM region where thefilters are stored. During forwarding, the ACLs are sequentiallyevaluated until a match is found.One reason to place filters in different regions is when they are addedwith decreasing priorities and in an alternating order so that twoconsecutive filters can never fit in the same region because of theirkey usage.In Spectrum-2 and newer ASICs the firmware started to report that themaximum number of ACLs in a group is more than 16, but the layout of theregister that configures ACL groups (PAGT) was not updated to accountfor that. It is therefore possible to hit stack corruption [1] in therare case where more than 16 ACLs in a group are required.Fix by limiting the maximum ACL group size to the minimum between whatthe firmware reports and the maximum ACLs that fit in the PAGT register.Add a test case to make sure the machine does not crash when thiscondition is hit.[1]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120[...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b 2024-02-22