CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50276 – net: vertexcom: mse102x: Fix possible double free of TX skb
https://notcve.org/view.php?id=CVE-2024-50276
In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660) • https://git.kernel.org/stable/c/2f207cbf0dd44278af2aa3ff0fc95b0f97cc4e4c https://git.kernel.org/stable/c/2cf0e77f5a0aa1ff336aa71743eda55c73902187 https://git.kernel.org/stable/c/1325e838089da25217f4b403318a270fcdf88f34 https://git.kernel.org/stable/c/91c9daa21f3ff8668f9e1d6c860024ce7ad64137 https://git.kernel.org/stable/c/1f26339b2ed63d1e8e18a18674fb73a392f3660e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50275 – arm64/sve: Discard stale CPU state when handling SVE traps
https://notcve.org/view.php?id=CVE-2024-50275
In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. • https://git.kernel.org/stable/c/cccb78ce89c45a4414db712be4986edfb92434bd https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7 https://git.kernel.org/stable/c/fa9ce027b3ce37a2bb173bf2553b5caa438fd8c9 https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a6052315552c0483d18 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50273 – btrfs: reinitialize delayed ref list after deleting it from the list
https://notcve.org/view.php?id=CVE-2024-50273
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead. • https://git.kernel.org/stable/c/1d57ee941692d0cc928526e21a1557b2ae3e11db https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d https://git.kernel.org/stable/c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb https://git.kernel.org/stable/c/bf0b0c6d159767c0d1c21f793950d78486690ee0 https://git.kernel.org/stable/c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851 https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6 https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e99931 https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50272 – filemap: Fix bounds checking in filemap_read()
https://notcve.org/view.php?id=CVE-2024-50272
In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. • https://git.kernel.org/stable/c/c2a9737f45e27d8263ff9643f994bda9bac0b944 https://git.kernel.org/stable/c/272830350bb1bb5bb39395966ea63b9864b135d1 https://git.kernel.org/stable/c/fbc7b803831e5c8a42c1f3427a17e55a814d6b3c https://git.kernel.org/stable/c/3d549dcfbbb0ecdaa571431a27ee5da9f2466716 https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235 https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826 https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50271 – signal: restore the override_rlimit logic
https://notcve.org/view.php?id=CVE-2024-50271
In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. • https://git.kernel.org/stable/c/d64696905554e919321e31afc210606653b8f6a4 https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1 https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7 https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40 https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed •