CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52835 – perf/core: Bail out early if the request AUX area is out of bound
https://notcve.org/view.php?id=CVE-2023-52835
In the Linux kernel, the following vulnerability has been resolved: perf/core: Bail out early if the request AUX area is out of bound When perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING. So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: rescate anticipado si el área AUX de la solicitud está fuera de los límites. Cuando perf-record con un área AUX grande, por ejemplo, 4 GB, falla con: #perf record -C 0 -m, 4G -e arm_spe_0// -- el sueño 1 no pudo mapear con 12 (no se puede asignar memoria) y revela una ADVERTENCIA con __alloc_pages(): ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 44 PID: 17573 en mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Rastreo de llamadas: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/ 0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' asignado por kcalloc() es una matriz de punteros que se utiliza para mantener páginas de seguimiento AUX. • https://git.kernel.org/stable/c/8c504f615d7ed60ae035c51d0c789137ced6797f https://git.kernel.org/stable/c/788c0b3442ead737008934947730a6d1ff703734 https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece https://git.kernel.org/stable/c/fd0df3f8719201dbe61a4d39083d5aecd705399a https://git.kernel.org/stable/c/9ce4e87a8efd37c85766ec08b15e885cab08553a https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb https://git.kernel.org/stable/c/54aee5f15b83437f23b2b2469bcf21bdd • CWE-125: Out-of-bounds Read •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52834 – atl1c: Work around the DMA RX overflow issue
https://notcve.org/view.php?id=CVE-2023-52834
In the Linux kernel, the following vulnerability has been resolved: atl1c: Work around the DMA RX overflow issue This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue"). The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester. Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address. Tested on AR8131 on Acer 4540. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atl1c:workaround al problema de desbordamiento de DMA RX. Esto se basa en la confirmación del controlador alx 881d0327db37 ("net: alx: solución alternativa al problema de desbordamiento de DMA RX"). Los controladores alx y atl1c tenían un error de desbordamiento de RX, por lo que se creó un asignador personalizado para evitar ciertas direcciones. • https://git.kernel.org/stable/c/c29a89b23f67ee592f4dee61f9d7efbf86d60315 https://git.kernel.org/stable/c/57e44ff9c2c9747b2b1a53556810b0e5192655d6 https://git.kernel.org/stable/c/54a6152da4993ec8e4b53dc3cf577f5a2c829afa https://git.kernel.org/stable/c/32f08b7b430ee01ec47d730f961a3306c1c7b6fb https://git.kernel.org/stable/c/86565682e9053e5deb128193ea9e88531bbae9cf https://access.redhat.com/security/cve/CVE-2023-52834 https://bugzilla.redhat.com/show_bug.cgi?id=2282744 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52833 – Bluetooth: btusb: Add date->evt_skb is NULL check
https://notcve.org/view.php?id=CVE-2023-52833
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Add date->evt_skb is NULL check fix crash because of null pointers [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btusb: Agregar fecha->evt_skb es un fallo de corrección de verificación NULL debido a punteros nulos [6104.969662] BUG: desreferencia del puntero NULL del kernel, dirección: 00000000000000c8 [6104.969667] #PF: supervisor acceso de lectura en modo kernel [6104.969668] #PF: error_code(0x0000) - página no presente [6104.969670] PGD 0 P4D 0 [6104.969673] Ups: 0000 [#1] SMP NOPTI [6104.969684] RIP: k_hci_wmt_sync+0x144/ 0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 00000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000006 [ 6104.969691] RDX: 00000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 000000000000000 0 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010DS : 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] : 55555554 [6104.969702] Seguimiento de llamadas: [6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [6104.969732] hci_dev_do_close+0x470/ 0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.9 69759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 0007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 00000000000000000 R09: 0000000000000017 [ 6104.969784] 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0 • https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3 https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0 https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30 https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9 •
CVSS: 9.1EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52832 – wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
https://notcve.org/view.php?id=CVE-2023-52832
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't return unset power in ieee80211_get_tx_power() We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: no devolver energía no configurada en ieee80211_get_tx_power(). Podemos obtener una advertencia de UBSAN si ieee80211_get_tx_power() devuelve el valor INT_MIN que mac80211 usa internamente para "nivel de energía no configurada". UBSAN: desbordamiento de entero con signo en net/wireless/nl80211.c:3816:5 -2147483648 * 100 no se puede representar en el tipo 'int' CPU: 0 PID: 20433 Comm: insmod Contaminado: G WC OE Call Trace: dump_stack+ 0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [.. .] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] En este caso, simplemente devuelva un error para indicar que no hay datos disponibles. • https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62 https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18 https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846 https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6 https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd67 • CWE-190: Integer Overflow or Wraparound CWE-920: Improper Restriction of Power Consumption •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52831 – cpu/hotplug: Don't offline the last non-isolated CPU
https://notcve.org/view.php?id=CVE-2023-52831
In the Linux kernel, the following vulnerability has been resolved: cpu/hotplug: Don't offline the last non-isolated CPU If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked(). cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Thus results in an empty CPU mask which triggers the warning and then the subsequent crash: WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798 Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU. Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpu/hotplug: no desconectar la última CPU no aislada. Si un sistema tiene CPU aisladas mediante el parámetro de línea de comando "isolcpus=", entonces se intenta desconectar la última limpieza La CPU dará como resultado un WARN_ON() al reconstruir los dominios del programador y un pánico posterior debido a una masa de CPU vacía no controlada en particion_sched_domains_locked(). cpuset_hotplug_workfn() build_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset. Effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Por lo tanto, se genera una máscara de CPU vacía que activa la advertencia y luego el bloqueo posterior: ADVERTENCIA: CPU: 4 PID: 80 en kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Seguimiento de llamadas: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+ 0x234/0x880 build_sched_domains_locked+0x37c/0x798 build_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 No se puede manejar la solicitud de paginación del kernel en la dirección virtual fffe80027ab37080 particion_sched_domains_locked+0x318/0x880 _sched_domains_locked+0x37c/0x798 Aparte del bloqueo resultante, no tiene ningún sentido para desconectar la última CPU de mantenimiento. Evite esto enmascarando las CPU que no son de mantenimiento al seleccionar una CPU de destino para iniciar la operación de desconexión de la CPU a través de la cola de trabajo. • https://git.kernel.org/stable/c/3410b702354702b500bde10e3cc1f9db8731d908 https://git.kernel.org/stable/c/335a47ed71e332c82339d1aec0c7f6caccfcda13 https://git.kernel.org/stable/c/3073f6df783d9d75f7f69f73e16c7ef85d6cfb63 https://git.kernel.org/stable/c/38685e2a0476127db766f81b1c06019ddc4c9ffa •