Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la desreferencia NULL al comprobar la banda al iniciar la sesión tx ba En la conexión MLD, link_data/link_conf se asignan dinámicamente. No apuntan a vif->bss_conf. Entonces, no habrá ningún chanreq asignado a vif->bss_conf y luego el chan será NULL. Modifique el código para verificar ht_supported/vht_supported/has_he/has_eht en sta deflink. Registro de fallos (con la versión rtw89 bajo desarrollo MLO): [9890.526087] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 [9890.526102] #PF: acceso de lectura del supervisor en modo kernel [9890.526105] #PF: error_code(0x0000) - no presente página [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Ups: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: cargado Contaminado: G OE 6.9.0 #1 [ 0010: ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminador 1)) mac80211 [ 9890.526279] Código: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 Todo el código ======== 0: f7 e8 imul %eax 2: d5 (malo) 3: 93 xchg %eax,%ebx 4: 3e ea ds (malo) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b : 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,( %rax) <-- instrucción de captura 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c : 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Código que comienza con la instrucción errónea ======================== ==================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 prueba %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP : 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 00000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] X: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 00000000000000000 R09: 0000000000000873 [ 9 890.526304] R10: ffff9308e0d64800 R11 : 000000000000000002 R12: FFFF9308E5FF6E70 [9890.526308] R13: FFFF930952500E20 R14: FFFF9309192A8C00 R15: 000000000000000000 [9890.526313] 4E700000 (0000) KNLGS: 000000000000000000 [9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 00000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Seguimiento de llamadas: [ 9890.526324] [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [9890.526335]? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [9890.526347]? search_module_extables (kernel/module/main.c:3256 (discriminador ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: no permite configurar anchos de canal AP especiales. La configuración del ancho del canal AP está manipulada para usarse con la progresión normal de ancho de canal de 20/40/... MHz y alternar entre No se admiten S1G ni canales estrechos. No permitir eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: evite BUG_ON() mientras continúa la remodelación después del reensamblaje. Actualmente, mdadm admite --revert-reshape para cancelar la remodelación mientras se reensambla, como muestra la prueba 07revert-grow. Sin embargo, la prueba puede activar el siguiente BUG_ON(): kernel ERROR en drivers/md/raid5.c:6278! código de operación no válido: 0000 [#1] PREEMPT SMP PTI sello de evento irq: 158985 CPU: 6 PID: 891 Comm: md0_reshape No contaminado 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Seguimiento de llamadas: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 La causa principal es que --revert-resha pe actualizar los raid_disks de 5 a 4, mientras la posición de remodelación aún está establecida, y después de volver a ensamblar la matriz, la posición de remodelación se leerá desde el superbloque, luego, durante la remodelación, fallará la verificación de 'writepos' calculada por la posición de remodelación anterior. Primero solucione este pánico de la manera más fácil, convirtiendo BUG_ON() en WARN_ON() y detenga la remodelación si las comprobaciones fallan. Se señaló que mdadm también debe corregir --revert-shape, y probablemente md/raid también debería mejorar la validación de metadatos; sin embargo, esto significa que el reensamblaje fallará y debe haber herramientas de usuario para corregir los metadatos incorrectos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: evita posibles fugas de especulación en gpio_device_get_desc() El espacio de usuario puede desencadenar una lectura especulativa de una dirección fuera de la matriz de descriptores de gpio. Los usuarios pueden hacerlo llamando a gpio_ioctl() con un desplazamiento fuera de rango. La compensación se copia del usuario y luego se usa como índice de matriz para obtener el descriptor de gpio sin desinfección en gpio_device_get_desc(). Este cambio garantiza que la compensación se desinfecte mediante el uso de array_index_nospec() para mitigar cualquier posibilidad de fugas de información especulativa. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mcast: espere los ciclos de gc anteriores al eliminar el puerto syzbot alcanzó un use-after-free [1] que se debe a que el puente no se asegura de que todos Se ha recogido basura anterior al eliminar un puerto. Lo que sucede es: CPU 1 CPU 2 iniciar el ciclo de gc eliminar el puerto adquirir el bloqueo de gc primero esperar la llamada de bloqueo br_multicasg_gc() adquirir directamente el bloqueo ahora pero liberar el puerto el puerto se puede liberar mientras los temporizadores de grp aún se ejecutan Asegúrese de que todos los ciclos de gc anteriores hayan finalizado usando flush_work antes de liberar el puerto. [1] ERROR: KASAN: slab-use-after-free en br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Lectura de tamaño 8 en la dirección ffff888071d6d000 por tarea syz.5.1232/9699 CPU: 1 PID: 9699 Comm : syz.5.1232 No contaminado 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c :88 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm /kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [en línea] __run_timers +0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [en línea] __run_timer_base kernel/time/timer.c:2421 [en línea] run_timer_base+0x111/0x190 kernel/time/timer. c:2437

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: sctp: corrige null-ptr-deref en reuseport_add_sock(). syzbot informó un null-ptr-deref al acceder a sk2->sk_reuseport_cb en reuseport_add_sock(). [0] La reproducción primero crea un oyente con SO_REUSEPORT. Luego, crea otro oyente en el mismo puerto y al mismo tiempo cierra el primer oyente. El segundo listen() llama a reuseport_add_sock() con el primer oyente como sk2, donde no se espera que sk2->sk_reuseport_cb se borre al mismo tiempo, pero close() lo borra mediante reuseport_detach_sock(). El problema es que SCTP no sincroniza correctamente reuseport_alloc(), reuseport_add_sock() y reuseport_detach_sock(). La persona que llama a reuseport_alloc() y reuseport_{add,detach}_sock() debe proporcionar sincronización para los sockets que están clasificados en el mismo grupo de reuseport. De lo contrario, dichos sockets forman múltiples grupos de reutilización idénticos y todos los grupos excepto uno quedarían silenciosamente muertos. 1. Dos sockets llaman a listening() simultáneamente 2. No se encuentra ningún socket en el mismo grupo en sctp_ep_hashtable[] 3. Dos sockets llaman a reuseport_alloc() y forman dos grupos de reuseport 4. Solo un grupo que llega primero en __sctp_rcv_lookup_endpoint() recibe paquetes entrantes también, podría producirse el null-ptr-deref informado. TCP/UDP garantiza que eso no sucederá si se mantiene el bloqueo del depósito hash. Apliquemos la estrategia de bloqueo a __sctp_hash_endpoint() y __sctp_unhash_endpoint(). [0]: Vaya: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 230 Comm: syz-executor119 No contaminado 6.10.0-syzkaller-12585-g301927d2d2eb #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/ sock_reuseport.c:350 Código: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 < 42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 X: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 00000000000000001 RDI: 0000000000000012 RBP : 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: ffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 : 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __sctp_hash_endpoint net/sctp/input.c:762 [en línea] sctp_hash_endpoint +0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [en línea] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [en línea ] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea] __se_sys_listen net/socket.c:1900 [en línea] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 arco x64/ x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Código: 28 00 00 00 75 05 8 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Tener formato de archivo honorífico EVENT_FILE_FL_FREED Cuando se introdujo eventfs, se tuvo que tener especial cuidado para coordinar la liberación de los metadatos del archivo con los archivos que están expuestos al espacio del usuario. Los metadatos del archivo tendrían un recuento de referencias que se establece cuando se crea el archivo y se reducirían y liberarían después de que el último usuario que abrió el archivo lo cerró. Cuando se iban a liberar los metadatos del archivo, se establecería un indicador (EVENT_FILE_FL_FREED) para indicar que el archivo está liberado, y cualquier nueva referencia realizada (como nuevas aperturas o lecturas) fallaría ya que se marca como liberado. Esto permitió liberar otros metadatos después de establecer este indicador (bajo event_mutex). Todos los archivos que se crearon dinámicamente en el directorio de eventos tenían un puntero a los metadatos del archivo y llamarían a event_release() cuando se cerrara la última referencia al archivo de espacio de usuario. Este sería el momento en el que será seguro liberar los metadatos del archivo. Se creó un acceso directo para el archivo "formato". Es i_private apuntaría a la entrada "llamar" directamente y no a los metadatos del archivo. Esto se debe a que todos los archivos de formato son iguales para una misma "llamada", por lo que se pensó que no había motivo para diferenciarlos. Los otros archivos mantienen el estado (como "habilitar", "activar", etc.). Pero esto significaba que si el archivo desapareciera, el archivo "formateado" no lo sabría. Esto provocó una ejecución que podría desencadenarse a través de la prueba user_events (que crearía eventos dinámicos y los liberaría) y ejecutar un bucle que leería los archivos de formato user_events: En una ejecución de consola: # cd tools/testing/selftests/user_events # si bien es cierto; hacer ./ftrace_test; hecho Y en otra consola ejecute: # cd /sys/kernel/tracing/ # while true; hacer eventos de gato/eventos_usuario/__test_event/formato; done 2>/dev/null Con la comprobación de memoria de KASAN, se activaría un informe de error de use-after-free (que era un error real). Esto se debía a que el archivo de formato no estaba verificando el indicador de metadatos del archivo "EVENT_FILE_FL_FREED", por lo que accedería al evento al que apuntaban los metadatos del archivo después de que se liberara el evento. Después de la inspección, se encontró que hay otras ubicaciones que no marcaban el indicador EVENT_FILE_FL_FREED al acceder a trace_event_file. Agregue una nueva función auxiliar: event_file_file() que garantizará que event_mutex se mantenga y devolverá NULL si trace_event_file tiene establecido el indicador EVENT_FILE_FL_FREED. Haga que la primera referencia del puntero del archivo de estructura use event_file_file() y verifique NULL. Los usos posteriores aún pueden usar la función auxiliar event_file_data() si event_mutex aún se mantiene y no se liberó desde la llamada event_file_file().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: cs-amp-lib: soluciona el fallo del puntero NULL si efi.get_variable es NULL Llame a efi_rt_services_supported() para comprobar que efi.get_variable existe antes de llamarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: verificación de integridad del puntero NULL después de ext4_force_shutdown Caso de prueba: 2 subprocesos escriben datos breves en línea en un archivo. En ext4_page_mkwrite se convierten los datos en línea resultantes. El manejo de ext4_grp_locked_error con la descripción "mapa de bits de bloque y descriptor de bg inconsistentes: clústeres libres X vs Y" llama a ext4_force_shutdown. La conversión borra EXT4_STATE_MAY_INLINE_DATA pero falla para ext4_destroy_inline_data_nolock y ext4_mark_iloc_dirty debido a ext4_forced_shutdown. La restauración de datos en línea falla por el mismo motivo al no configurar EXT4_STATE_MAY_INLINE_DATA. Sin el indicador establecido, una ruta de proceso normal en ext4_da_write_end sigue intentando eliminar la referencia al puntero privado de la página que no se ha configurado. La solución llama al retorno anticipado con el error -EIO y el puntero a privado será NULL. Informe de falla de muestra: No se puede manejar la solicitud de paginación del kernel en la dirección virtual dfff800000000004 KASAN: null-ptr-deref en el rango [0x000000000000020-0x00000000000000027] Información de cancelación de memoria: ESR = 0x0000000096000005 EC = 0x25: DABT (actual EL), IL = 32 bits CONJUNTO = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: error de traducción de nivel 1 Información de cancelación de datos: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 dirección [dfff800000000004] entre los rangos de direcciones del usuario y del kernel Error interno: Ups: 0000000096000005 [#1] Módulos SMP PREEMPT vinculados en: CPU: 1 PID: 20274 Comm: syz-executor185 No está contaminado 6.9.0-rc7-syzkaller-gfda5695d692c #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT - SSBS BTYPE=--) pc: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 lr: __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160 sp: ffff8000a1957600 x29: ffff8000a1957610 x28: 00000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25 : dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 00000000000000020 x20: 0000000000000040 x19: ffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 00000000000000000 x 12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: 0000000000000000 x8: 0000000000000004 x7: 0000000000000000 x6: 0000000000000000 x5: fffffdffc397c9c0 x4: 00000000000000020 x3: 0000000000000020 x2: 000 0000000000040 x1: 0000000000000020 x0: fffffdffc397c9c0 Rastreo de llamadas: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer .c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [en línea] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0 x4ecfs/ ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+ 0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/ núcleo /syscall.c:34 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/ kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/ arm64/kernel/entry.S:598 Código: 97f85911 f94002da 91008356 d343fec8 (38796908) ---[ end trace 00000000000000000 ]--------- TRUNCADO ----------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la desreferencia del puntero NULL para el registro DTN en DCN401 Cuando los usuarios ejecutan el comando: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log El siguiente puntero NULL ocurre la desreferencia: [+0.000003] ERROR: desreferencia del puntero NULL del kernel, dirección: NULL [+0.000005] #PF: búsqueda de instrucciones del supervisor en modo kernel [+0.000002] #PF: código_error(0x0010) - página no presente [+0.000002] PGD 0 P4D 0 [ +0.000004] Ups: 0010 [#1] PREEMPT SMP NOPTI [ +0.000003] RIP: 0010:0x0 [ +0.000008] Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. [...] [ +0.000002] PKRU: 55555554 [ +0.000002] Seguimiento de llamadas: [ +0.000002] [ +0.000003] ? show_regs+0x65/0x70 [+0.000006]? __die+0x24/0x70 [ +0.000004] ? page_fault_oops+0x160/0x470 [+0.000006]? do_user_addr_fault+0x2b5/0x690 [+0.000003]? prb_read_valid+0x1c/0x30 [+0.000005]? exc_page_fault+0x8c/0x1a0 [+0.000005]? asm_exc_page_fault+0x27/0x30 [ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu] [ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000003]? vsnprintf+0x2fb/0x600 [ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu] [ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170 [ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? debug_smp_processor_id+0x17/0x20 [+0.000003]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? set_ptes.isra.0+0x2b/0x90 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? _raw_spin_unlock+0x19/0x40 [+0.000004]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? do_anonymous_page+0x337/0x700 [ +0.000004] dtn_log_read+0x82/0x120 [amdgpu] [ +0.000207] full_proxy_read+0x66/0x90 [ +0.000007] vfs_read+0xb0/0x340 [ +0.000005] ? __count_memcg_events+0x79/0xe0 [+0.000002]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000003]? count_memcg_events.constprop.0+0x1e/0x40 [+0.000003]? handle_mm_fault+0xb2/0x370 [ +0.000003] ksys_read+0x6b/0xf0 [ +0.000004] __x64_sys_read+0x19/0x20 [ +0.000003] do_syscall_64+0x60/0x130 [ +0.000004] _64_after_hwframe+0x6e/0x76 [+0.000003] RIP: 0033:0x7fdf32f147e2 [...] Este error ocurre cuando el registro de color intenta leer la información de reasignación de gama de DCN401 que no está inicializada en dcn401_dpp_funcs, lo que conduce a una desreferencia del puntero nulo. Esta confirmación soluciona este problema agregando una protección adecuada para acceder a la devolución de llamada gamut_remap en caso de que el ASIC específico no haya implementado esta función.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: agregue una verificación NULL para 'afb' antes de eliminar la referencia en amdgpu_dm_plane_handle_cursor_update. Esta confirmación agrega una verificación nula para la variable 'afb' en la función amdgpu_dm_plane_handle_cursor_update. Anteriormente, se suponía que 'afb' era nulo, pero se usó más adelante en el código sin una verificación de nulo. Potencialmente, esto podría conducir a una desreferencia del puntero nulo. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 error amdgpu_dm_plane_handle_cursor_update(): anteriormente asumimos que 'afb' podría ser nulo (consulte la línea 1252)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/admgpu: corrige la desreferenciación del contexto del puntero nulo Cuando el espacio de usuario establece un tipo ta no válido, el contexto del puntero estará vacío. Por lo tanto, es necesario verificar el contexto del puntero antes de usarlo.