CVSS: 5.3EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48711 – tipc: improve size validations for received domain records
https://notcve.org/view.php?id=CVE-2022-48711
In the Linux kernel, the following vulnerability has been resolved: tipc: improve size validations for received domain records The function tipc_mon_rcv() allows a node to receive and process domain_record structs from peer nodes to track their views of the network topology. This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAX_MON_DOMAIN, something that may otherwise lead to a stack overflow. tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where we are reading a 32 bit message data length field into a uint16. To avert any risk of bit overflow, we add an extra sanity check for this in that function. We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer. This potential problem was identified by Eric Dumazet. This fixes CVE-2022-0435 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: mejorar las validaciones de tamaño para los registros de dominio recibidos. La función tipc_mon_rcv() permite que un nodo reciba y procese estructuras domain_record de nodos pares para rastrear sus vistas de la topología de la red. • https://git.kernel.org/stable/c/35c55c9877f8de0ab129fa1a309271d0ecc868b9 https://git.kernel.org/stable/c/175db196e45d6f0e6047eccd09c8ba55465eb131 https://git.kernel.org/stable/c/fde4ddeadd099bf9fbb9ccbee8e1b5c20d530a2d https://git.kernel.org/stable/c/f1af11edd08dd8376f7a84487cbb0ea8203e3a1d https://git.kernel.org/stable/c/d692e3406e052dbf9f6d9da0cba36cb763272529 https://git.kernel.org/stable/c/3c7e5943553594f68bbc070683db6bb6f6e9e78e https://git.kernel.org/stable/c/1f1788616157b0222b0c2153828b475d95e374a7 https://git.kernel.org/stable/c/59ff7514f8c56f166aadca49bcecfa028 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47620 – Bluetooth: refactor malicious adv data check
https://notcve.org/view.php?id=CVE-2021-47620
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: refactor malicious adv data check Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: refactorización de verificación de datos publicitarios maliciosos. Se estaba realizando una verificación de lectura fuera de los límites al final del bucle while num_reports y llenaría el diario con falsos positivos. Se agregó una verificación al comienzo del procesamiento del bucle para que no se verifique después de que se haya avanzado ptr. • https://git.kernel.org/stable/c/305e92f525450f3e1b5f5c9dc7eadb152d66a082 https://git.kernel.org/stable/c/7889b38a7f21ed19314f83194622b195d328465c https://git.kernel.org/stable/c/5a539c08d743d9910631448da78af5e961664c0e https://git.kernel.org/stable/c/8819f93cd4a443dfe547aa622b21f723757df3fb https://git.kernel.org/stable/c/835d3706852537bf92eb23eb8635b8dee0c0aa67 https://git.kernel.org/stable/c/83d5196b65d1b29e27d7dd16a3b9b439fb1d2dba https://git.kernel.org/stable/c/bcea886771c3f22a590c8c8b9139a107bd7f1e1c https://git.kernel.org/stable/c/5c968affa804ba98c3c603f37ffea6fba •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47619 – i40e: Fix queues reservation for XDP
https://notcve.org/view.php?id=CVE-2021-47619
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix queues reservation for XDP When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? • https://git.kernel.org/stable/c/41c445ff0f482bb6e6b72dcee9e598e20575f743 https://git.kernel.org/stable/c/d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b https://git.kernel.org/stable/c/be6998f232b8e4ca8225029e305b8329d89bfd59 https://git.kernel.org/stable/c/768eb705e6381f0c70ca29d4e66f19790d5d19a1 https://git.kernel.org/stable/c/00eddb0e4ea115154581d1049507a996acfc2d3e https://git.kernel.org/stable/c/4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8 https://git.kernel.org/stable/c/92947844b8beee988c0ce17082b705c2f75f0742 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47618 – ARM: 9170/1: fix panic when kasan and kprobe are enabled
https://notcve.org/view.php?id=CVE-2021-47618
In the Linux kernel, the following vulnerability has been resolved: ARM: 9170/1: fix panic when kasan and kprobe are enabled arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9170/1: soluciona el pánico cuando kasan y kprobe están habilitados arm32 usa software para simular la instrucción reemplazada por kprobe. Algunas instrucciones pueden simularse mediante la construcción de funciones de ensamblaje. por lo tanto, antes de ejecutar la simulación de instrucciones, es necesario construir un entorno de ejecución de funciones de ensamblaje en lenguaje C mediante registros vinculantes. después de habilitar kasan, la relación de enlace de registros se destruirá, lo que provocará errores de simulación de instrucciones y provocará pánico en el kernel. La función de emulación de instrucciones de kprobe se distribuye en tres archivos: acciones-common.c acciones-arm.c acciones-thumb.c, por lo tanto, desactive KASAN al compilar estos archivos. por ejemplo, use kprobe insert en cap_capable+20 después de habilitar kasan, el código ensamblador de cap_capable es el siguiente: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c agregue r0, r0, #108; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [ordenador personal, #144]; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108]; 0x6c e2859014 add r9, r5, #20 ...... El código ensamblador emulate_ldr después de habilitar kasan es el siguiente: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c agregue r8, r2, #60; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load 4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f y sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, 4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 agregar r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 14 bne c06f1430 e1a06000 mov r6, r0 e2840040 agregar r0, r4, #64; 0x40 ...... cuando se ejecuta emulate_ldr para simular la instrucción ldr, se produce pánico y el registro es el siguiente: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, * pmd=00000000 Error interno: Ups: 206 [#1] La PC SMP ARM está en cap_capable+0x14/0xb0 LR está en emulate_ldr+0x50/0xc0 psr: 600d0293 sp: ecd63af8 ip: 00000004 fp: c0a7c30c r10: r9: c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Banderas: nZCv IRQ desactivadas FIQ activadas Modo SVC_3 2 Usuario de segmento ISA ARM Control: 32c5387d Tabla: 2d546400 DAC: 55555555 Proceso bash (pid: 1643, límite de pila = 0xecd60190) (cap_capable) de (kprobe_handler+0x218/0x340) (kprobe_handler) de (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) de (do_undefinstr+0x13c/0x364) (do_undefinstr) de (__ und_svc_finish+ 0x0/0x30) (__und_svc_finish) de (cap_capable+0x18/0xb0) (cap_capable) de (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) de (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) de (copy_process .constprop.5+0x16b4/ 0x25c8) (copy_process.constprop.5) de (_do_fork+0xe8/0x55c) (_do_fork) de (SyS_clone+0x1c/0x24) (SyS_clone) de (__sys_trace_return+0x0/0x10) Código: 0050a0e1 6c0080e2 0260a0e1 (f801f0e7) • https://git.kernel.org/stable/c/35aa1df4328340f38edc46f00837f08d33d49f63 https://git.kernel.org/stable/c/1515e72aae803fc6b466adf918e71c4e4c9d5b3d https://git.kernel.org/stable/c/ba1863be105b06e10d0e2f6b1b8a0570801cfc71 https://git.kernel.org/stable/c/8b59b0a53c840921b625378f137e88adfa87647e •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47617 – PCI: pciehp: Fix infinite loop in IRQ handler upon power fault
https://notcve.org/view.php?id=CVE-2021-47617
In the Linux kernel, the following vulnerability has been resolved: PCI: pciehp: Fix infinite loop in IRQ handler upon power fault The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pciehp: soluciona el bucle infinito en el controlador IRQ ante un fallo de alimentación. • https://git.kernel.org/stable/c/a8cc52270f3d8e8f4faf01ffd6c4a95bbfb55ba4 https://git.kernel.org/stable/c/4667358dab9cc07da044d5bc087065545b1000df https://git.kernel.org/stable/c/8edf5332c39340b9583cf9cba659eb7ec71f75b5 https://git.kernel.org/stable/c/ff27f7d0333cff89ec85c419f431aca1b38fb16a https://git.kernel.org/stable/c/464da38ba827f670deac6500a1de9a4f0f44c41d https://git.kernel.org/stable/c/3b4c966fb156ff3e70b2526d964952ff7c1574d9 https://git.kernel.org/stable/c/1db58c6584a72102e98af2e600ea184ddaf2b8af https://git.kernel.org/stable/c/6d6f1f0dac3e3441ecdb1103d4efb11b9 •