CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26906 – x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()
https://notcve.org/view.php?id=CVE-2024-26906
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault() When trying to use copy_from_kernel_nofault() to read vsyscall page through a bpf program, the following oops was reported: BUG: unable to handle page fault for address: ffffffffff600000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:copy_from_kernel_nofault+0x6f/0x110 ...... Call Trace: <TASK> ? copy_from_kernel_nofault+0x6f/0x110 bpf_probe_read_kernel+0x1d/0x50 bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d trace_call_bpf+0xc5/0x1c0 perf_call_bpf_enter.isra.0+0x69/0xb0 perf_syscall_enter+0x13e/0x200 syscall_trace_enter+0x188/0x1c0 do_syscall_64+0xb5/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ...... ---[ end trace 0000000000000000 ]--- The oops is triggered when: 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall page and invokes copy_from_kernel_nofault() which in turn calls __get_user_asm(). 2) Because the vsyscall page address is not readable from kernel space, a page fault exception is triggered accordingly. 3) handle_page_fault() considers the vsyscall page address as a user space address instead of a kernel space address. This results in the fix-up setup by bpf not being applied and a page_fault_oops() is invoked due to SMAP. Considering handle_page_fault() has already considered the vsyscall page address as a userspace address, fix the problem by disallowing vsyscall page read for copy_from_kernel_nofault(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/mm: no permitir la lectura de la página vsyscall para copy_from_kernel_nofault() Al intentar usar copy_from_kernel_nofault() para leer la página vsyscall a través de un programa bpf, se informó lo siguiente: ERROR: no se puede manejar el error de página para la dirección: ffffffffff600000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) ...... RIP: 0010:copy_from_kernel_nofault+0x6f/0x110... ... • https://git.kernel.org/stable/c/6e4694e65b6db4c3de125115dd4f55848cc48381 https://git.kernel.org/stable/c/e8a67fe34b76a49320b33032228a794f40b0316b https://git.kernel.org/stable/c/f175de546a3eb77614d94d4c02550181c0a8493e https://git.kernel.org/stable/c/57f78c46f08198e1be08ffe99c4c1ccc12855bf5 https://git.kernel.org/stable/c/29bd6f86904682adafe9affbc7f79b14defcaff8 https://git.kernel.org/stable/c/32019c659ecfe1d92e3bf9fcdfbb11a7c70acd58 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-20: Improper Input Validation •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26903 – Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
https://notcve.org/view.php?id=CVE-2024-26903
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. • https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85 https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96 https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0 https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73 https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5 https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26902 – perf: RISCV: Fix panic on pmu overflow handler
https://notcve.org/view.php?id=CVE-2024-26902
In the Linux kernel, the following vulnerability has been resolved: perf: RISCV: Fix panic on pmu overflow handler (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e [ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74 [ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92 [ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ end trace 0000000000000000 ]--- [ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: RISCV: no se desea corregir el pánico en el controlador de desbordamiento de pmu (1 << idx) de int al configurar bits en overflowed_ctrs largos sin firmar; use BIT() en su lugar. Este pánico ocurre cuando se ejecuta 'perf record -e sucursales' en sophgo sg2042. [273.311852] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000098 [273.320851] Ups [#1] [273.323179] Módulos vinculados en: [273.326303] CPU: 0 PID: 1475 Comm: perf No contaminado 6.6.0- rc3+#9 [ 273.332521] Nombre de hardware: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffff80aecd98 ra: ffffffff80aee056 sp: ffffff6e36928b0 [273.354454] gp: ffffffff821f82d0 tp : ffffffd90c353200 T0: 0000002ade4f9978 [273.361815] T1: 000000000000504D55 T2: FFFFFFFF8016CD8C S0: FFFFFFF66E3692A70 [273.369180] 1A8E81800000 [273.376540] A2: 0000003C00070198 A3: 0000003C00DB75A4 A4: 000000000000000015 [273.383901] A5: FFFFFFD7FF8804B0 A6: 0000000000000015 a7: 000000000000002a [273.391327] s2: 000000000000ffff s3: 0000000000000000 s4: ffffffd7ff8803b0 [273.398773] s5: 0000000000504d55 s6: ffffffd905069800 s7: ffffffff821fe210 [273.406139] s8: 000000007ffffff s9: ffffffd7ff8803b0 s10: ffffffd903f29098 [273.413660] s11: 00080000000 t3: 0000000000000003 t4: ffffffff8017a0ca [273.421022] t5: ffffffff8023cfc2 t6: ffffffd9040780e8 [273.426437] estado: 0000000200000100 badaddr: 0000000000000098 causa: 00000d [ 273.434512] [] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562 ] [] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [] riscv_intc_irq+0x36/0x4e [ 273.459659] [] 0x4a/0x74 [ 273.465442] [] do_irq+0x62/0x92 [ 273.470360] Código: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ final de seguimiento 0000000000000000 ]--- 273.482 630] Pánico del kernel: no se sincroniza: excepción fatal en la interrupción • https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9 https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6 https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26878 – quota: Fix potential NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-26878
In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cuota: corrige una posible desreferencia del puntero NULL La siguiente carrera puede causar una desreferencia del puntero NULL P1 P2 dquot_free_inode quote_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[tipo] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... Si dquot_free_inode(u otras rutinas) verifica los punteros de cuota del inodo (1) antes de que cuota_off lo establezca a NULL(2) y usarlo (3) después de eso, se activará la desreferencia del puntero NULL. • https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1 https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0 https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0 https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25 https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754 https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5 https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7 https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583 • CWE-476: NULL Pointer Dereference •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26846 – nvme-fc: do not wait in vain when unloading module
https://notcve.org/view.php?id=CVE-2024-26846
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. • https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2 https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17 https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9 https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67 https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •