CVSS: 4.7EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43880 – mlxsw: spectrum_acl_erp: Fix object nesting warning
https://notcve.org/view.php?id=CVE-2024-43880
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_erp: Fix object nesting warning ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. • https://git.kernel.org/stable/c/9069a3817d82b01b3a55da382c774e3575946130 https://git.kernel.org/stable/c/4dc09f6f260db3c4565a4ec52ba369393598f2fb https://git.kernel.org/stable/c/36a9996e020dd5aa325e0ecc55eb2328288ea6bb https://git.kernel.org/stable/c/9a5261a984bba4f583d966c550fa72c33ff3714e https://git.kernel.org/stable/c/25c6fd9648ad05da493a5d30881896a78a08b624 https://git.kernel.org/stable/c/0e59c2d22853266704e127915653598f7f104037 https://git.kernel.org/stable/c/fb5d4fc578e655d113f09565f6f047e15f7ab578 https://git.kernel.org/stable/c/97d833ceb27dc19f8777d63f90be4a27b • CWE-284: Improper Access Control •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43879 – wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
https://notcve.org/view.php?id=CVE-2024-43879
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. • https://git.kernel.org/stable/c/c4cbaf7973a794839af080f13748335976cf3f3f https://git.kernel.org/stable/c/45d20a1c54be4f3173862c7b950d4468447814c9 https://git.kernel.org/stable/c/b289ebb0516526cb4abae081b7ec29fd4fa1209d https://git.kernel.org/stable/c/2e201b3d162c6c49417c438ffb30b58c9f85769f https://git.kernel.org/stable/c/576c64622649f3ec07e97bac8fec8b8a2ef4d086 https://git.kernel.org/stable/c/16ad67e73309db0c20cc2a651992bd01c05e6b27 https://git.kernel.org/stable/c/67b5f1054197e4f5553047759c15c1d67d4c8142 https://git.kernel.org/stable/c/19eaf4f2f5a981f55a265242ada2bf92b • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43875 – PCI: endpoint: Clean up error handling in vpci_scan_bus()
https://notcve.org/view.php?id=CVE-2024-43875
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure. • https://git.kernel.org/stable/c/e2b6ef72b7aea9d7d480d2df499bcd1c93247abb https://git.kernel.org/stable/c/e35f56bb03304abc92c928b641af41ca372966bb https://git.kernel.org/stable/c/24414c842a24d0fd498f9db6d2a762a8dddf1832 https://git.kernel.org/stable/c/7d368de78b60088ec9031c60c88976c0063ea4c0 https://git.kernel.org/stable/c/0e27e2e8697b8ce96cdef43f135426525d9d1f8f https://git.kernel.org/stable/c/b9e8695246bcfc028341470cbf92630cdc1ba36b https://git.kernel.org/stable/c/8e0f5a96c534f781e8c57ca30459448b3bfe5429 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43873 – vhost/vsock: always initialize seqpacket_allow
https://notcve.org/view.php?id=CVE-2024-43873
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features • https://git.kernel.org/stable/c/ced7b713711fdd8f99d8d04dc53451441d194c60 https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582 https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43872 – RDMA/hns: Fix soft lockup under heavy CEQE load
https://notcve.org/view.php?id=CVE-2024-43872
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. • https://git.kernel.org/stable/c/a5073d6054f75d7c94b3354206eec4b804d2fbd4 https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08 https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b •