Page 65 of 1965 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 … CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 … Call Trace: <TASK> ? __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? • https://git.kernel.org/stable/c/84a433a40d0ebf3bbf36b8bfa58c6f45dc782344 https://git.kernel.org/stable/c/5d07d1d40aabfd61bab21115639bd4f641db6002 https://git.kernel.org/stable/c/98884e89c90d077f6fe6ba18e6cf6f914642f04e https://git.kernel.org/stable/c/091268f3c27a5b6d7858a3bb2a0dbcc9cd26ddb5 https://git.kernel.org/stable/c/572f9caa9e7295f8c8822e4122c7ae8f1c412ff9 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel. • https://git.kernel.org/stable/c/07037db5d479f90377c998259a4f9a469c404edf https://git.kernel.org/stable/c/59be4a167782d68e21068a761b90b01fadc09146 https://git.kernel.org/stable/c/20dbdebc5580cd472a310d56a6e252275ee4c864 https://git.kernel.org/stable/c/d7ccf2ca772bfe33e2c53ef80fa20d2d87eb6144 https://git.kernel.org/stable/c/917f598209f3f5e4ab175d5079d8aeb523e58b1f https://git.kernel.org/stable/c/d4e7db757e2d7f4c407a007e92c98477eab215d2 https://git.kernel.org/stable/c/0c710050c47d45eb77b28c271cddefc5c785cb40 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path. • https://git.kernel.org/stable/c/ed42e8ff509d2a61c6642d1825032072dab79f26 https://git.kernel.org/stable/c/41a6c31df77bd8e050136b0a200b537da9e1084a https://git.kernel.org/stable/c/08775b3d6ed117cf4518754ec7300ee42b6a5368 https://git.kernel.org/stable/c/3f480493550b6a23d3a65d095d6569d4a7f56a0f https://git.kernel.org/stable/c/5db999fff545b924b24c9afd368ef5c17279b176 https://git.kernel.org/stable/c/da72e783afd27d9f487836b2e6738146c0edd149 https://git.kernel.org/stable/c/1171ceccabfd596ca370c5d2cbb47d110c3f2fe1 https://git.kernel.org/stable/c/8aa37bde1a7b645816cda8b80df4753ec •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) Linux i915 suffers from an out-of-bounds PTE write in vm_fault_gtt() that leads to a PTE use-after-free vulnerability. • https://git.kernel.org/stable/c/c58305af1835095ddc25ee6f548ac05915e66ac5 https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60 https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39 https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7 https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2d •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: pca953x: corrige la ejecución pca953x_irq_bus_sync_unlock Asegúrese de que se mantenga `i2c_lock' al configurar el bloqueo de interrupción y la máscara en pca953x_irq_bus_sync_unlock() para evitar ejecuciones. El otro sitio de llamada (que no es de sonda) pca953x_gpio_set_multiple() garantiza que el bloqueo se mantenga antes de llamar a pca953x_write_regs(). El problema ocurrió cuando una solicitud corrió contra irq_bus_sync_unlock() aproximadamente una vez por cada mil reinicios en un sistema basado en i.MX8MP. * Caso normal 0-0022: escribir registro AI|3a {03,02,00,00,01} Enclavamiento de entrada P0 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 0 -0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|12 {fc,00,00,00,00} Configuración P3 * Caso de ejecución 0-0022: escribir registro AI|08 {ff,00,00,00,00} Salida P3 0-0022: escribir registro AI|08 {03,02,00,00,01} *** Registro incorrecto *** 0-0022: escribir registro AI|12 {fc,00,00,00,00} Config P3 0-0022: escribir registro AI|49 {fc,fd,ff,ff,fe} Máscara de interrupción P0 • https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34 https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2 https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41 https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904 •