CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46832 – MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed
https://notcve.org/view.php?id=CVE-2024-46832
In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices". • https://git.kernel.org/stable/c/d3ff0f98a52f0aafe35aa314d1c442f4318be3db https://git.kernel.org/stable/c/e6cd871627abbb459d0ff6521d6bb9cf9d9f7522 https://git.kernel.org/stable/c/b1d2051373bfc65371ce4ac8911ed984d0178c98 https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30 https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52 https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46830 – KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
https://notcve.org/view.php?id=CVE-2024-46830
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory. Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm] stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? • https://git.kernel.org/stable/c/f7e570780efc5cec9b2ed1e0472a7da14e864fdb https://git.kernel.org/stable/c/080dbe7e9b86a0392d8dffc00d9971792afc121f https://git.kernel.org/stable/c/e302786233e6bc512986d007c96458ccf5ca21c7 https://git.kernel.org/stable/c/b4c0d89c92e957ecccce12e66b63875d0cc7af7e https://git.kernel.org/stable/c/fa297c33faefe51e10244e8a378837fca4963228 https://git.kernel.org/stable/c/939375737b5a0b1bf9b1e75129054e11bc9ca65e https://git.kernel.org/stable/c/ecdbe8ac86fb5538ccc623a41f88ec96c7168ab9 https://git.kernel.org/stable/c/4bcdd831d9d01e0fb64faea50732b59b2 •
CVSS: -EPSS: 0%CPEs: 14EXPL: 0CVE-2024-46829 – rtmutex: Drop rt_mutex::wait_lock before scheduling
https://notcve.org/view.php?id=CVE-2024-46829
In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ] • https://git.kernel.org/stable/c/3d5c9340d1949733eb37616abd15db36aef9a57c https://git.kernel.org/stable/c/95f9aded9436aa3ce714aeff3f45fcc1431df7d2 https://git.kernel.org/stable/c/ea018da95368adfb700689bd9842714f7c3db665 https://git.kernel.org/stable/c/1201613a70dd34bd347ba2970919b3f1d5fbfb4a https://git.kernel.org/stable/c/a2e64fcdc83c645813f7b93e4df291841ba7c625 https://git.kernel.org/stable/c/fb52f40e085ef4074f1335672cd62c1f832af13b https://git.kernel.org/stable/c/2b1f3807ed9cafb59c956ce76a05d25e67103f2e https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab144 •
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 •