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: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26851 – netfilter: nf_conntrack_h323: Add protection for bmp length out of range
https://notcve.org/view.php?id=CVE-2024-26851
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: Add protection for bmp length out of range UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type. vmlinux get_bitmap(b=75) + 712 <net/netfilter/nf_conntrack_h323_asn1.c:0> vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 <net/netfilter/nf_conntrack_h323_asn1.c:592> vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812 <net/netfilter/nf_conntrack_h323_asn1.c:576> vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux DecodeRasMessage() + 304 <net/netfilter/nf_conntrack_h323_asn1.c:833> vmlinux ras_help() + 684 <net/netfilter/nf_conntrack_h323_main.c:1728> vmlinux nf_confirm() + 188 <net/netfilter/nf_conntrack_proto.c:137> Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_conntrack_h323: Agregar protección para longitud de bmp fuera de rango La carga de UBSAN informa una excepción de BRK#5515 SHIFT_ISSUE: desplazamientos bit a bit que están fuera de los límites para su tipo de datos. vmlinux get_bitmap(b=75) + 712 vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, nivel=134443100) + 1956 vmlinux decode_choice (base=0xFFFFFFD0080370F0, nivel=23843636) + 1216 vmlinux decode_seq(f=0xFFFFFFD0080371A8, nivel=134443500) + 812 vmlinux decode_choice(base =0xFFFFFFD008037280, nivel=0) + 1216 vmlinux DecodeRasMessage() + 304 vmlinux ras_help() + 684 vmlinux nf_confirm() + 188 Debido a datos anormales en skb->data, la longitud del mapa de bits de la extensión excede 32 cuando se decodifica el mensaje ras y luego usa la longitud para realizar una operación de cambio . Cambiará a negativo después de varios bucles. • https://git.kernel.org/stable/c/5e35941d990123f155b02d5663e51a24f816b6f3 https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13 https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591 https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff75008 • CWE-20: Improper Input Validation •
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') CWE-415: Double Free •