CVSS: 5.5EPSS: 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 https://access.redhat.com/security/cve/CVE-2023-52831 https://bugzilla.redhat.com/show_bug.cgi?id=2282740 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 6.6EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52828 – bpf: Detect IP == ksym.end as part of BPF program
https://notcve.org/view.php?id=CVE-2023-52828
In the Linux kernel, the following vulnerability has been resolved: bpf: Detect IP == ksym.end as part of BPF program Now that bpf_throw kfunc is the first such call instruction that has noreturn semantics within the verifier, this also kicks in dead code elimination in unprecedented ways. For one, any instruction following a bpf_throw call will never be marked as seen. Moreover, if a callchain ends up throwing, any instructions after the call instruction to the eventually throwing subprog in callers will also never be marked as seen. The tempting way to fix this would be to emit extra 'int3' instructions which bump the jited_len of a program, and ensure that during runtime when a program throws, we can discover its boundaries even if the call instruction to bpf_throw (or to subprogs that always throw) is emitted as the final instruction in the program. An example of such a program would be this: do_something(): ... r0 = 0 exit foo(): r1 = 0 call bpf_throw r0 = 0 exit bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // Never seen by verifier exit // main(ctx): r1 = ... call bar r0 = 0 exit Here, if we do end up throwing, the stacktrace would be the following: bpf_throw foo bar main In bar, the final instruction emitted will be the call to foo, as such, the return address will be the subsequent instruction (which the JIT emits as int3 on x86). This will end up lying outside the jited_len of the program, thus, when unwinding, we will fail to discover the return address as belonging to any program and end up in a panic due to the unreliable stack unwinding of BPF programs that we never expect. To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as part of the BPF program, so that is_bpf_text_address returns true when such a case occurs, and we are able to unwind reliably when the final instruction ends up being a call instruction. • https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18 https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1 https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5 https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922 https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52826 – drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
https://notcve.org/view.php?id=CVE-2023-52826
In the Linux kernel, the following vulnerability has been resolved: drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel/panel-tpo-tpg110: corrige una posible desreferencia del puntero null. En tpg110_get_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a un Desreferencia del puntero NULL en caso de fallo de drm_mode_duplicate(). Agregue una marca para evitar npd. • https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52825 – drm/amdkfd: Fix a race condition of vram buffer unref in svm code
https://notcve.org/view.php?id=CVE-2023-52825
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix a race condition of vram buffer unref in svm code prange->svm_bo unref can happen in both mmu callback and a callback after migrate to system ram. Both are async call in different tasks. Sync svm_bo unref operation to avoid random "use-after-free". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: se corrige una condición de ejecución de vram buffer unref en el código svm prange->svm_bo unref puede ocurrir tanto en la devolución de llamada mmu como en una devolución de llamada después de migrar a la memoria RAM del sistema. Ambas son llamadas asíncronas en diferentes tareas. • https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34 https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659 https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52821 – drm/panel: fix a possible null pointer dereference
https://notcve.org/view.php?id=CVE-2023-52821
In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: corrige una posible desreferencia del puntero null. En versatile_panel_get_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd. • https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1 https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190 https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402 https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4 https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992 https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229 • CWE-476: NULL Pointer Dereference •