Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: corrección para devolver errno si kmalloc() falla. En create_unique_id(), kmalloc(, GFP_KERNEL) puede fallar debido a falta de memoria, si falla, regrese errno correctamente en lugar de provocar pánico mediante BUG_ON(); ¡ERROR del kernel en mm/slub.c:5893! Error interno: Ups - ERROR: 0 [#1] Seguimiento de llamada SMP PREEMPT: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [ en línea] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [en línea] f2fs_init_xattr_caches+0x 78/0xb4 fs/f2fs/xattr. c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 Legacy_get_tree+0x30/0x74 fs/ fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [ en línea] __do_sys_mount fs/namespace.c:3591 [en línea] __se_sys_mount fs/namespace.c:3568 [en línea] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpiolib: cdev: configure lineevent_state::irq después del registro IRQ con éxito Al ejecutar la prueba gpio en la plataforma nxp-ls1028 con el siguiente comando gpiomon --num-events=3 --rising-edge gpiochip1 25 Habrá un seguimiento de advertencia como se muestra a continuación: Seguimiento de llamada: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... 0x1a0/0x1a4 El motivo de este problema es que falló la llamada a la función request_threaded_irq() y luego se invoca lineevent_free() para liberar el recurso. Dado que lineevent_state::irq ya estaba configurado, la invocación posterior de free_irq() activaría el seguimiento de llamada de advertencia anterior. Para solucionar este problema, configure lineevent_state::irq después del registro IRQ correctamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige una posible fuga de recursos al registrar un chip. Si falla la creación del nodo de software, la matriz de cadenas asignada localmente queda sin liberar. Libérelo en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gem: realmente mueva i915_gem_context.link bajo protección de referencia. i915_perf supone que puede usar la referencia i915_gem_context para proteger su iteración i915->gem.contexts.list. Sin embargo, esto requiere que no eliminemos el contexto de la lista hasta que eliminemos la referencia final y liberemos la estructura. Si, como actualmente, eliminamos el contexto de la lista durante context_close(), el puntero link.next puede envenenarse mientras mantenemos la referencia de contexto y provocar un GPF: [ 4070.573157] i915 0000:00:02.0: [drm: i915_perf_open_ioctl [i915]] filtrado en ctx_id=0x1fffff ctx_id_mask=0x1fffff [4070.574881] falla de protección general, probablemente para dirección no canónica 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] : 1 PID: 284392 Comunicaciones: AMD_Performance Contaminado: GE 5.17.9 #180 [ 4070.574903] Nombre del hardware: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 18/09/2017 [ 4070.574907] RIP: oa_configure_all_contexts.is ra.0+0x222/0x350 [i915] [ 4070.574982] Código: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] : 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI : ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: ffffffffffffffc [ 4070.575008] R10: 2c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: muerto0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.57501 6]FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Seguimiento de llamadas: [ 4070.575033] [ 4070.575037 ] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.5 75224] ? asm_common_interrupt+0x1e/0x40 [4070.575232]? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [4070.575382]? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0x7f1ed5c10397 [ 4070.575471] Código: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 X: 00007f1ed5c10397 [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006 [ 4070.575492] RBP: 00005620972f9c 60 R08: 000000000000000a R09: 0000000000000005 [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a [ 4070.575500] R13: 000000000000000d R14: 0000000000 R15: 00007ffd65c8d7c0 [ 4070.575505] [ 4070.575507] Módulos vinculados en: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl( E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige la desreferencia del puntero NULL al eliminar debugfs Ahora eliminamos las entradas debugfs del dispositivo al desvincular el controlador. Esto ahora provoca una desreferencia del puntero NULL al salir del módulo porque los dispositivos de la plataforma no están registrados *después* de que el directorio global debugfs se haya eliminado de forma recursiva. Solucionarlo cancelando el registro de los dispositivos primero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fsdax: Reparar bucle infinito en dax_iomap_rw() Obtuve un bucle infinito y un informe de ADVERTENCIA al ejecutar un comando tail en virtiofs. ADVERTENCIA: CPU: 10 PID: 964 en fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Módulos vinculados en: CPU: 10 PID: 964 Comm: tail No contaminado 5.19.0-rc7 Seguimiento de llamadas: dax_iomap_rw +0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd El comando tail llamará a read() con un recuento de 0. En este caso, iomap_iter() informará esto ADVERTENCIA, y siempre devuelve 1, lo que provoca el bucle infinito en dax_iomap_rw(). Arreglando verificando el recuento si es 0 en dax_iomap_rw().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige error en el análisis de extensiones cuando eh_entries == 0 y eh_ Depth > 0 Al recorrer las extensiones de un inodo, la función ext4_ext_binsearch_idx() asume que el encabezado de la extensión ha sido validado previamente. Sin embargo, no hay comprobaciones que verifiquen que el número de entradas (eh->eh_entries) sea distinto de cero cuando la profundidad es > 0. Y esto generará problemas porque EXT_FIRST_INDEX() y EXT_LAST_INDEX() devolverán basura y darán como resultado esto: [135.245946] ------------[ cortar aquí ]------------ [ 135.247579] ¡ERROR del kernel en fs/ext4/extents.c:2258! [ 135.249045] código de operación no válido: 0000 [#1] SMP PREEMPT [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 No contaminado 5.19.0-rc8+ #4 [ 135.252067] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) , BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 [135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [135.256475] Código: [135.261433] RSP: ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000000 3 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 00000000000002602 R 11: 0000000000000000 R12: 0000000000000024 [ 135.270477 ] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) ) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3 : 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Seguimiento de llamadas: [ 135.278635] [ 135.279247] ? preempt_count_add+0x6d/0xa0 [135.280358]? ¿percpu_counter_add_batch+0x55/0xb0 [135.281612]? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [135.284562] ext4_mpage_readpages+0x3d6/0x770 [135.285646] read_pages+0x67/0x1d0 [135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [135.290332] filemap_read+0xbf/0x300 [135.291158]? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] Entry_SYSCALL_64_after_hwframe+0x46/0xb0 Este parche simplemente agrega un verificación adicional en __ext4_ext_check(), verificando que eh_entries no sea 0 cuando eh_ Depth sea > 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: mlxbf: evita el desbordamiento de pila en mlxbf_i2c_smbus_start_transaction() memcpy() se llama en un bucle mientras que el límite superior 'operation->length' no está marcado y 'data_idx' también aumenta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/gma500: Se solucionó el error WARN_ON(lock->magic!= lock) psb_gem_unpin() llama a dma_resv_lock() pero el ww_mutex subyacente es destruido por drm_gem_object_release() mueve drm_gem_object_release() llame a psb_gem_free_object() después de desanclar para corregir la siguiente advertencia: [79.693962] ------------[ cortar aquí ]------------ [ 79.693992] DEBUG_LOCKS_WARN_ON (lock->magic!= lock) [79.694015] ADVERTENCIA: CPU: 0 PID: 240 en kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [79.694052] Módulos vinculados en: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap pcspkr genérico wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: GWE 6.0.0-rc3+ 0 [79.694457] Nombre del hardware: Packard Bell puntos s /SJE01_CT, BIOS V1.10 23/07/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Código: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0000000000000028 RBX: 00000000000000000 RCX: 000000000000000000000 [ 79 .694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff [ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: 0 [79.694662] R10 : 0000000000000003 R11: fffffffaad62fe8 R12: ffff9ff302103138 [ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270 [ 79.694 690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000 [ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0 [ 79.694734] Seguimiento de llamadas: [ 79.694749] [ 79.694761] ? __programar+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [79.694830]? lock_is_held_type+0xe3/0x140 [79.694864]? ww_mutex_lock+0x38/0xa0 [79.694885]? __cond_resched+0x1c/0x30 [ 79.694902] ww_mutex_lock+0x38/0xa0 [ 79.694925] psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694964] psb_gem_unpin+0x199/0x1a0 ma500_gfx] [79.694996] drm_gem_object_release_handle+0x50/0x60 [79.695020]? drm_gem_object_handle_put_unlocked+0xf0/0xf0 [ 79.695042] idr_for_each+0x4b/0xb0 [ 79.695066] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 79.695095] drm_gem_release+0x1c/0x30 [ 79.695118] drm_file_free.part.0+0x1ea/0x260 [ 79.695150] drm_release+0x6a/0x120 [ 79.695175 ] __fput+0x9f/0x260 [ 79.695203] task_work_run+0x59/0xa0 [ 79.695227] do_exit+0x387/0xbe0 [ 79.695250] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [79.695275]? lockdep_hardirqs_on+0x7d/0x100 [ 79.695304] do_group_exit+0x33/0xb0 [ 79.695331] __x64_sys_exit_group+0x14/0x20 [ 79.695353] do_syscall_64+0x58/0x80 [ 79.69 5376] ? up_read+0x17/0x20 [ 79.695401] ? lock_is_held_type+0xe3/0x140 [79.695429]? asm_exc_page_fault+0x22/0x30 [79.695450]? lockdep_hardirqs_on+0x7d/0x100 [ 79.695473] Entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 79.695493] RIP: 0033:0x7ff1ccefe3f1 [ 79.695516] Código: No se puede acceder a los bytes del código de operación en RIP 0x7ff1ccefe3 c7. [79.695607] RSP: 002b:00007ffed4413378 EFLAGS: ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/gma500: Corrección de ERROR: función inactiva llamada desde errores de contexto no válidos gma_crtc_page_flip() estaba manteniendo el spinlock event_lock mientras llamaba a crtc_funcs->mode_set_base() que toma ww_mutex. La única razón para mantener event_lock es borrar los errores de gma_crtc->page_flip_event en mode_set_base(). En su lugar, desbloquéelo después de configurar gma_crtc->page_flip_event y, en caso de errores, vuelva a tomar el bloqueo y borre gma_crtc->page_flip_event si todavía está configurado. Esto corrige la siguiente ADVERTENCIA/stacktrace: [512.122953] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/mutex.c:870 [512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, nombre: gnome-shell [512.123031] preempt_count: 1, esperado: 0 [512.123048] Profundidad del nido de RCU: 0, esperado: 0 [512.123066] INFORMACIÓN: lockdep está desactivado. [ 512.123080] sello de evento irq: 0 [ 512.123094] hardirqs habilitado por última vez en (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs deshabilitado por última vez en (0): [] copy_process+0x9fc/0x1de0 [ 5 12.123176] softirqs habilitado por última vez en (0): [] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs deshabilitado por última vez en (0): [<0000000000000000>] 0x0 [ 512.123233] Preferencia deshabilitada en: [ 512.123241] 0000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comunicaciones: gnome-shell Contaminado: GW 5.19.0+ #1 [ 512.123304] Nombre de hardware: Packard Bell dot s/SJE01_CT, BIOS V1.10 23/07/2013 [ 512.123323] Seguimiento de llamadas : [ 512.123346] [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495 ] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76 /0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [512.124070]? rcu_read_lock_bh_held+0xb/0x60 [512.124104]? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [512.124267]? trace_hardirqs_on_prepare+0x55/0xe0 [512.124300]? do_syscall_64+0x67/0x80 [512.124340]? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] Entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Código: 00 48 89 44 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 24470]RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 7ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 12.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647 ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/dasd: corrige Ups en dasd_alias_get_start_dev debido a la falta de pavgroup. Corrige Ups en la función dasd_alias_get_start_dev() causada porque el puntero pavgroup es NULL. El puntero pavgroup se verifica en la entrada de la función pero sin que se mantenga presionado el bloqueo lcu->. Por lo tanto, existe una ventana de ejecución entre dasd_alias_get_start_dev() y _lcu_update() que establece pavgroup en NULL con el bloqueo lcu->retenido. Para solucionarlo, compruebe el puntero de pavgroup con lcu->lock retenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt: impide que skb UAF se entregue al trabajador de PTP. Cuando se requiere leer la marca de tiempo, bnxt_tx_int() entrega la propiedad del skb completado al trabajador de PTP. El skb no debe usarse después, ya que el trabajador puede ejecutarse antes que el resto de nuestro código y liberar el skb, lo que lleva a un use-after-free. Dado que dev_kfree_skb_any() acepta NULL, la pérdida de propiedad es más obvia y establece skb en NULL.