CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46828 – sched: sch_cake: fix bulk flow accounting logic for host fairness
https://notcve.org/view.php?id=CVE-2024-46828
In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). • https://git.kernel.org/stable/c/712639929912c5eefb09facccb48d55b3f72c9f8 https://git.kernel.org/stable/c/4a4eeefa514db570be025ab46d779af180e2c9bb https://git.kernel.org/stable/c/7725152b54d295b7da5e34c2f419539b30d017bd https://git.kernel.org/stable/c/cde71a5677971f4f1b69b25e854891dbe78066a4 https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094 https://git.kernel.org/stable/c/d4a9039a7b3d8005b90c7b1a55a306444f0e5447 https://git.kernel.org/stable/c/d7c01c0714c04431b5e18cf17a9ea68a553d1c3c https://git.kernel.org/stable/c/546ea84d07e3e324644025e2aae2d12ea •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46826 – ELF: fix kernel.randomize_va_space double read
https://notcve.org/view.php?id=CVE-2024-46826
In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec. • https://git.kernel.org/stable/c/1f81d51141a234ad0a3874b4d185dc27a521cd27 https://git.kernel.org/stable/c/53f17409abf61f66b6f05aff795e938e5ba811d1 https://git.kernel.org/stable/c/1cf8cd80903073440b6ea055811d04edd24fe4f7 https://git.kernel.org/stable/c/2a97388a807b6ab5538aa8f8537b2463c6988bd2 https://access.redhat.com/security/cve/CVE-2024-46826 https://bugzilla.redhat.com/show_bug.cgi?id=2315178 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46825 – wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check
https://notcve.org/view.php?id=CVE-2024-46825
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON(). • https://git.kernel.org/stable/c/415f3634d53c7fb4cf07d2f5a0be7f2e15e6da33 https://git.kernel.org/stable/c/3cca098c91391b3fa48142bfda57048b985c87f6 https://git.kernel.org/stable/c/9215152677d4b321801a92b06f6d5248b2b4465f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46823 – kunit/overflow: Fix UB in overflow_allocation_test
https://notcve.org/view.php?id=CVE-2024-46823
In the Linux kernel, the following vulnerability has been resolved: kunit/overflow: Fix UB in overflow_allocation_test The 'device_name' array doesn't exist out of the 'overflow_allocation_test' function scope. However, it is being used as a driver name when calling 'kunit_driver_create' from 'kunit_device_register'. It produces the kernel panic with KASAN enabled. Since this variable is used in one place only, remove it and pass the device name into kunit_device_register directly as an ascii string. • https://git.kernel.org/stable/c/d1207f07decc66546a7fa463d2f335a856c986ef https://git.kernel.org/stable/c/92e9bac18124682c4b99ede9ee3bcdd68f121e92 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46822 – arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
https://notcve.org/view.php?id=CVE-2024-46822
In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility. • https://git.kernel.org/stable/c/f57769ff6fa7f97f1296965f20e8a2bb3ee9fd0f https://git.kernel.org/stable/c/4c3b21204abb4fa3ab310fbbb5cf7f0e85f3a1bc https://git.kernel.org/stable/c/945be49f4e832a9184c313fdf8917475438a795b https://git.kernel.org/stable/c/40cae0df42e5e7f7a1c0f32deed9c4027c1ba94e https://git.kernel.org/stable/c/62ca6d3a905b4c40cd942f3cc645a6718f8bc7e7 https://git.kernel.org/stable/c/bc7fbb37e3d2df59336eadbd6a56be632e3c7df7 https://git.kernel.org/stable/c/2488444274c70038eb6b686cba5f1ce48ebb9cdd •