Page 72 of 2989 results (0.006 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: validate nvme_local_port correctly The driver load failed with error message, qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef and with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port. • https://git.kernel.org/stable/c/549aac9655320c9b245a24271b204668c5d40430 https://git.kernel.org/stable/c/e1f010844443c389bc552884ac5cfa47de34d54c https://git.kernel.org/stable/c/a3ab508a4853a9f5ae25a7816a4889f09938f63c https://git.kernel.org/stable/c/cde43031df533751b4ead37d173922feee2f550f https://git.kernel.org/stable/c/7cec2c3bfe84539c415f5e16f989228eba1d2f1e https://git.kernel.org/stable/c/f6be298cc1042f24d521197af29c7c4eb95af4d5 https://git.kernel.org/stable/c/3eac973eb5cb2b874b3918f924798afc5affd46b https://git.kernel.org/stable/c/eb1d4ce2609584eeb7694866f34d4b213 •

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

In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp). • https://git.kernel.org/stable/c/af69fb3a8ffa37e986db00ed93099dc44babeef4 https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803 https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3 https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2 https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629 https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80 https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7 https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef7 •

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 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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 •

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

In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cierres: Cambie BUG_ON() a WARN_ON() Si se puede acceder a un BUG_ON() en estado salvaje, no debería ser un BUG_ON() Como referencia, ha aparecido esto una vez en el CI, y necesitaremos más información para depurarlo: 03240 ------------[ cortar aquí ]------------ 03240 ERROR del kernel en lib /cierre.c:21! 03240 ERROR del kernel en lib/closure.c:21! 03240 Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP 03240 Módulos vinculados en: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 No contaminado 6.10.0-rc4-ktest-ga56da69799bd #25570 Nombre del hardware: linux,dummy-virt (DT) 03240 Cola de trabajo: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc: cierre_put+0x224/0x2a0 03240 lr: cierre_put+0x24/ 0x2a0 03240 sp: ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16 : 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: e402d x10: dfff800000000000 x9: ffff6000183e402e 03240 x8: 0000000000000001 x7: 00009fffe7c1bfd3 x6: ffff0000c1f2016b 03240 x5: 0168 x4: ffff6000183e402e x3: ffff800081391954 03240 x2: 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Rastreo de llamadas: 03240 cierre_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c /0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 Process_scheduled_works+0x53c/0xd90 03240 trabajador_thread+0x37 0/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Código: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000 ) 03240 ---[ seguimiento final 0000000000000000 ]--- 03240 Pánico del kernel - no se sincroniza: Ups - ERROR: Excepción fatal 03240 SMP: deteniendo las CPU secundarias 03241 SMP: no se pudieron detener las CPU secundarias 13,15 03241 Desplazamiento del kernel: deshabilitado 03241 CPU características: 0x00,00000003,80000008,4240500b 03241 Límite de memoria: ninguno 03241 ---[ fin del pánico del kernel - no se sincroniza: Ups - ERROR: excepción fatal ]--- 03246 ========= TIEMPO DE ESPERA FALLIDO copygc_torture_no_checksum en 7200 • https://git.kernel.org/stable/c/5d85f2ab79d5918a66539ebf046c099f7448db8d https://git.kernel.org/stable/c/339b84ab6b1d66900c27bd999271cb2ae40ce812 •