Page 157 of 2767 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. • https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25 https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige la condición de ejecución entre la búsqueda de sesión y la caducidad del subproceso A + subproceso B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sesiones, sesión->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // ¡UAF! | sess->last_active = jiffies | + Este parche agrega rwsem para corregir la condición de ejecución entre ksmbd_session_lookup y ksmbd_expire_session. • https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige uaf en smb20_oplock_break_ack elimina la referencia después de usar opinfo. • https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930 https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9 https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce •

CVSS: 6.0EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!) • https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1 https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528 https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. • https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81 https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3 https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81 https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289 https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891 • CWE-476: NULL Pointer Dereference •