CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35989 – dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
https://notcve.org/view.php?id=CVE-2024-35989
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: soluciona errores durante rmmod en plataformas de CPU única Durante la eliminación del controlador idxd, se invoca la devolución de llamada sin conexión registrada como parte del proceso de limpieza. Sin embargo, en sistemas con una sola CPU en línea, no hay ningún destino válido disponible para migrar el contexto de rendimiento, lo que genera un error del kernel: ERROR: no se puede manejar el error de página para la dirección: 000000000002a2b8 #PF: acceso de escritura del supervisor en modo kernel #PF: error_code(0x0002) - página no presente PGD 1470e1067 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 No contaminado 6.8.0-rc6-dsa+ #57 Nombre de hardware: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 18/07/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Seguimiento de llamadas: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault++0x65 /0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 f_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0 x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Solucione el problema impidiendo la migración del contexto de rendimiento a un destino no válido. • https://git.kernel.org/stable/c/81dd4d4d6178306ab31db91bdc7353d485bdafce https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be https://access.redhat.com/security/cve/CVE-2024-35989 https://bugzilla.redhat.com/show_bug.cgi?id=2281847 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35988 – riscv: Fix TASK_SIZE on 64-bit NOMMU
https://notcve.org/view.php?id=CVE-2024-35988
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: corrige TASK_SIZE en NOMMU de 64 bits En NOMMU, la memoria del espacio de usuario puede provenir de cualquier lugar de la RAM física. La definición actual de TASK_SIZE es incorrecta si existe RAM por encima de 4G, lo que provoca fallos falsos en las rutinas de acceso al espacio de usuario. • https://git.kernel.org/stable/c/6bd33e1ece528f67646db33bf97406b747dafda0 https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6 https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2 https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35986 – phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered
https://notcve.org/view.php?id=CVE-2024-35986
In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: ti: tusb1210: resolver el bloqueo del cargador-det si el cargador psy no está registrado. El marco power_supply no está realmente manipulado para que haya referencias duraderas en el kernel a los dispositivos power_supply. Específicamente, cancelar el registro de un power_supply mientras algún otro código tiene una referencia a él activa una ADVERTENCIA en power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Seguido por power_supply aún se elimina y los datos de respaldo se liberan de todos modos, dejando el código de detección del cargador tusb1210 con una referencia colgante, lo que resulta en un bloqueo la próxima vez que se llama a tusb1210_get_online(). • https://git.kernel.org/stable/c/48969a5623ed918713552e2b4f9d391c89b5e838 https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8 https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588 https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35984 – i2c: smbus: fix NULL function pointer dereference
https://notcve.org/view.php?id=CVE-2024-35984
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: smbus: corrige la desreferencia del puntero de función NULL. Baruch informó de un OOPS al usar el controlador de designware como destino únicamente. Los modos de solo objetivo rompen el supuesto de que siempre hay una función de transferencia disponible. • https://git.kernel.org/stable/c/63453b59e41173241c4efe9335815f6432fa8586 https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23 https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620 https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85 https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d04 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35983 – bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
https://notcve.org/view.php?id=CVE-2024-35983
In the Linux kernel, the following vulnerability has been resolved: bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: límites: utilice el número correcto de bits para potencia de dos CONFIG_NR_CPUS bits_per() redondea a la siguiente potencia de dos cuando se pasa una potencia de dos. Esto provoca fallos en algunas máquinas y configuraciones. • https://git.kernel.org/stable/c/d6077e0d38b4953c863d0db4a5b3f41d21e0d546 https://git.kernel.org/stable/c/83a2275f9d3230c761014b1467888b1ef469be74 https://git.kernel.org/stable/c/d2a7a81088c6abe778b0a93a7eeb79487a943818 https://git.kernel.org/stable/c/428ca0000f0abd5c99354c52a36becf2b815ca21 https://git.kernel.org/stable/c/b46c822f8b555b9513df44047b0e72c06720df62 https://git.kernel.org/stable/c/cf778fff03be1ee88c49b72959650147573c3301 https://git.kernel.org/stable/c/b2e1b090a590d41abe647eadb6bf2a5dc47b63ab https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3 •