Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: usb-mixer: us16x08: validar los índices de los paquetes de medidor<br /> <br /> get_meter_levels_from_urb() analiza los paquetes de medidor de 64 bytes enviados por el dispositivo y rellena los arrays por canal meter_level[], comp_level[] y master_level[] en la estructura snd_us16x08_meter_store.<br /> <br /> Actualmente, la función deriva el índice del canal directamente del paquete de medidor (MUB2(meter_urb, s) - 1) y lo usa para indexar esos arrays sin validar el rango. Si el paquete contiene un número de canal negativo o fuera de rango, el controlador puede escribir más allá del final de estos arrays.<br /> <br /> Introduce una variable de canal local y valídala antes de actualizar los arrays. Rechazamos los índices negativos, limitamos meter_level[] y comp_level[] a SND_US16X08_MAX_CHANNELS, y protegemos las actualizaciones de master_level[] con ARRAY_SIZE(master_level).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfs: soluciona un problema de UAF en la reparación de xattr<br /> <br /> La función xchk_setup_xattr_buf puede asignar un nuevo búfer de valor, lo que significa que cualquier referencia a ab-&amp;gt;value antes de la llamada podría convertirse en un puntero colgante. Soluciona esto moviendo una asignación a después de la configuración del búfer.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: openvswitch: corrige la validación del atributo intermedio en la acción push_nsh()<br /> <br /> La estructura de la acción push_nsh() se ve así:<br /> <br /> OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))<br /> <br /> El atributo más externo OVS_ACTION_ATTR_PUSH_NSH es validado por nla_for_each_nested() dentro de __ovs_nla_copy_actions(). Los atributos más internos OVS_NSH_KEY_ATTR_BASE/MD1/MD2 son validados por nla_for_each_nested() dentro de nsh_key_put_from_nlattr(). Pero nada verifica si el atributo del medio es válido. Ni siquiera verificamos que este atributo sea OVS_KEY_ATTR_NSH. Simplemente hacemos un doble unwrap con un par de llamadas a nla_data() - la primera vez directamente al llamar a validate_push_nsh() y la segunda vez como parte de la macro nla_for_each_nested(), lo cual no es seguro, pudiendo causar acceso a memoria inválido si el tamaño de este atributo es incorrecto. El fallo podría no ser notado durante la validación debido a un búfer netlink más grande, pero causar problemas más tarde durante la ejecución de la acción donde el búfer se asigna exactamente al tamaño:<br /> <br /> BUG: KASAN: slab-out-of-bounds en nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]<br /> Lectura de tamaño 184 en la dirección ffff88816459a634 por la tarea a.out/22624<br /> <br /> CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)<br /> Traza de Llamadas:<br /> <br /> dump_stack_lvl+0x51/0x70<br /> print_address_description.constprop.0+0x2c/0x390<br /> kasan_report+0xdd/0x110<br /> kasan_check_range+0x35/0x1b0<br /> __asan_memcpy+0x20/0x60<br /> nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]<br /> push_nsh+0x82/0x120 [openvswitch]<br /> do_execute_actions+0x1405/0x2840 [openvswitch]<br /> ovs_execute_actions+0xd5/0x3b0 [openvswitch]<br /> ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]<br /> genl_family_rcv_msg_doit+0x1d6/0x2b0<br /> genl_family_rcv_msg+0x336/0x580<br /> genl_rcv_msg+0x9f/0x130<br /> netlink_rcv_skb+0x11f/0x370<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x73e/0xaa0<br /> netlink_sendmsg+0x744/0xbf0<br /> __sys_sendto+0x3d6/0x450<br /> do_syscall_64+0x79/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> Añadamos algunas verificaciones de que el atributo tiene el tamaño adecuado y es el único atributo dentro de la acción. Técnicamente, no hay una razón real para que OVS_KEY_ATTR_NSH esté allí, ya que sabemos que ya estamos pusheando un encabezado NSH, solo crea anidamiento adicional, pero así es como funciona la uAPI hoy. Así que, lo mantenemos como está.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: omitir la comprobación del rango de bloqueo en tamaño igual para evitar el desbordamiento negativo cuando size==0<br /> <br /> Cuando size es igual al i_size actual (incluyendo 0), el código solía llamar a check_lock_range(filp, i_size, size - 1, WRITE), que calcula size - 1 y puede sufrir un desbordamiento negativo cuando size==0. Omitir el caso de igualdad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netrom: Corrección de fuga de memoria en nr_sendmsg()<br /> <br /> syzbot informó una fuga de memoria [1].<br /> <br /> Cuando la función sock_alloc_send_skb() devuelve NULL en nr_output(), el<br /> skb original no se libera, el cual fue asignado en nr_sendmsg(). Corrija esto<br /> liberándolo antes de regresar.<br /> <br /> [1]<br /> ERROR: fuga de memoria<br /> objeto sin referencia 0xffff888129f35500 (tamaño 240):<br /> comm &amp;#39;syz.0.17&amp;#39;, pid 6119, jiffies 4294944652<br /> volcado hexadecimal (primeros 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(....<br /> rastreo (crc 1456a3e4):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4983 [inline]<br /> slab_alloc_node mm/slub.c:5288 [inline]<br /> kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340<br /> __alloc_skb+0x203/0x240 net/core/skbuff.c:660<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671<br /> sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965<br /> sock_alloc_send_skb include/net/sock.h:1859 [inline]<br /> nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> sock_write_iter+0x293/0x2a0 net/socket.c:1195<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x45d/0x710 fs/read_write.c:686<br /> ksys_write+0x143/0x170 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fsnotify: no generar eventos ACCESS/MODIFY en el hijo para archivos especiales<br /> <br /> inotify/fanotify no permiten a los usuarios sin acceso de lectura a un archivo suscribirse a eventos (p. ej., IN_ACCESS/IN_MODIFY), pero sí permiten al mismo usuario suscribirse para observar eventos en los hijos cuando el usuario tiene acceso al directorio padre (p. ej., /dev).<br /> <br /> Los usuarios sin acceso de lectura a un archivo pero con acceso de lectura a su directorio padre aún pueden hacer stat al archivo y ver si fue accedido/modificado a través de un cambio en atime/mtime.<br /> <br /> Lo mismo no es cierto para archivos especiales (p. ej., /dev/null). Los usuarios generalmente no observarán cambios en atime/mtime cuando otros usuarios leen/escriben en archivos especiales, solo cuando alguien establece atime/mtime a través de utimensat().<br /> <br /> Alinear los eventos de fsnotify con este comportamiento de stat y no generar eventos ACCESS/MODIFY a los observadores padre en la lectura/escritura de archivos especiales. Los eventos aún se generan a los observadores padre en utimensat(). Esto cierra algunos canales laterales que podrían ser posiblemente utilizados para la exfiltración de información [1].<br /> <br /> [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/handshake: las cancelaciones duplicadas de handshake fugan el socket<br /> <br /> Cuando una solicitud de handshake es cancelada, es eliminada de la lista handshake_net-&amp;gt;hn_requests, pero aún está presente en la handshake_rhashtbl hasta que es destruida.<br /> <br /> Si llega una segunda solicitud de cancelación para la misma solicitud de handshake, entonces remove_pending() devolverá falso... y asumiendo que HANDSHAKE_F_REQ_COMPLETED no está establecido en req-&amp;gt;hr_flags, continuaremos procesando a través de la etiqueta out_true, donde ponemos otra referencia en el sock y ocurre un desbordamiento negativo del contador de referencias.<br /> <br /> Esto puede ocurrir por ejemplo si un handshake agota el tiempo de espera, particularmente si el cliente SUNRPC envía la sonda AUTH_TLS al servidor pero no la sigue con el ClientHello debido a un problema con tlshd. Cuando se alcanza el tiempo de espera en el servidor, el servidor enviará un FIN, lo que activa una solicitud de cancelación a través de xs_reset_transport(). Cuando se alcanza el tiempo de espera en el cliente, ocurre otra solicitud de cancelación a través de xs_tls_handshake_sync().<br /> <br /> Añadir un test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) en la ruta de cancelación pendiente para que las cancelaciones duplicadas puedan ser detectadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/hsr: corrección de desreferencia de puntero NULL en prp_get_untagged_frame()<br /> <br /> prp_get_untagged_frame() llama a __pskb_copy() para crear frame-&amp;gt;skb_std, pero no comprueba si la asignación falló. Si __pskb_copy() devuelve NULL, se llama a skb_clone() con un puntero NULL, lo que provoca un fallo:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041<br /> Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 &amp;lt;43&amp;gt; 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c<br /> RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207<br /> RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480<br /> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000<br /> RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee<br /> R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000<br /> R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00<br /> FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline]<br /> hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741<br /> hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84<br /> __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966<br /> __netif_receive_skb_one_core net/core/dev.c:6077 [inline]<br /> __netif_receive_skb+0x72/0x380 net/core/dev.c:6192<br /> netif_receive_skb_internal net/core/dev.c:6278 [inline]<br /> netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337<br /> tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485<br /> tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953<br /> tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x5c9/0xb30 fs/read_write.c:686<br /> ksys_write+0x145/0x250 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0449f8e1ff<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 &amp;lt;48&amp;gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48<br /> RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff<br /> RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8<br /> RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001<br /> R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003<br /> <br /> <br /> Añadir una comprobación de NULL inmediatamente después de __pskb_copy() para manejar los fallos de asignación de forma elegante.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Input: ti_am335x_tsc - corrige error de uno en la validación de &amp;#39;wire_order&amp;#39;<br /> <br /> La validación actual &amp;#39;wire_order[i] &amp;gt; ARRAY_SIZE(config_pins)&amp;#39; permite que wire_order[i] sea igual a ARRAY_SIZE(config_pins), lo que causa acceso fuera de límites cuando se usa como índice en &amp;#39;config_pins[wire_order[i]]&amp;#39;.<br /> <br /> Dado que config_pins tiene 4 elementos (índices 0-3), el rango válido para wire_order debería ser 0-3. Corrige el error de uno usando &amp;#39;&amp;gt;=&amp;#39; en lugar de &amp;#39;&amp;gt;&amp;#39; en la comprobación de validación.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t log conflicting inode if it&amp;#39;s a dir moved in the current transaction<br /> <br /> We can&amp;#39;t log a conflicting inode if it&amp;#39;s a directory and it was moved<br /> from one parent directory to another parent directory in the current<br /> transaction, as this can result an attempt to have a directory with<br /> two hard links during log replay, one for the old parent directory and<br /> another for the new parent directory.<br /> <br /> The following scenario triggers that issue:<br /> <br /> 1) We have directories "dir1" and "dir2" created in a past transaction.<br /> Directory "dir1" has inode A as its parent directory;<br /> <br /> 2) We move "dir1" to some other directory;<br /> <br /> 3) We create a file with the name "dir1" in directory inode A;<br /> <br /> 4) We fsync the new file. This results in logging the inode of the new file<br /> and the inode for the directory "dir1" that was previously moved in the<br /> current transaction. So the log tree has the INODE_REF item for the<br /> new location of "dir1";<br /> <br /> 5) We move the new file to some other directory. This results in updating<br /> the log tree to included the new INODE_REF for the new location of the<br /> file and removes the INODE_REF for the old location. This happens<br /> during the rename when we call btrfs_log_new_name();<br /> <br /> 6) We fsync the file, and that persists the log tree changes done in the<br /> previous step (btrfs_log_new_name() only updates the log tree in<br /> memory);<br /> <br /> 7) We have a power failure;<br /> <br /> 8) Next time the fs is mounted, log replay happens and when processing<br /> the inode for directory "dir1" we find a new INODE_REF and add that<br /> link, but we don&amp;#39;t remove the old link of the inode since we have<br /> not logged the old parent directory of the directory inode "dir1".<br /> <br /> As a result after log replay finishes when we trigger writeback of the<br /> subvolume tree&amp;#39;s extent buffers, the tree check will detect that we have<br /> a directory a hard link count of 2 and we get a mount failure.<br /> The errors and stack traces reported in dmesg/syslog are like this:<br /> <br /> [ 3845.729764] BTRFS info (device dm-0): start tree-log replay<br /> [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c<br /> [ 3845.731236] memcg:ffff9264c02f4e00<br /> [ 3845.731751] aops:btree_aops [btrfs] ino:1<br /> [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8<br /> [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00<br /> [ 3845.735305] page dumped because: eb page dump<br /> [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir<br /> [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5<br /> [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701<br /> [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384<br /> [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [ 3845.737797] rdev 0 sequence 2 flags 0x0<br /> [ 3845.737798] atime 1764259517.0<br /> [ 3845.737800] ctime 1764259517.572889464<br /> [ 3845.737801] mtime 1764259517.572889464<br /> [ 3845.737802] otime 1764259517.0<br /> [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [ 3845.737805] index 0 name_len 2<br /> [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34<br /> [ 3845.737808] location key (257 1 0) type 2<br /> [ 3845.737810] transid 9 data_len 0 name_len 4<br /> [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34<br /> [ 3845.737813] location key (258 1 0) type 2<br /> [ 3845.737814] transid 9 data_len 0 name_len 4<br /> [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [ 3845.737816] location key (257 1 0) type 2<br /> [<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: Evitar desregistrar PSP dos veces<br /> <br /> PSP se desregistra dos veces en:<br /> _mlx5e_remove -&amp;gt; mlx5e_psp_unregister<br /> mlx5e_nic_cleanup -&amp;gt; mlx5e_psp_unregister<br /> <br /> Esto conduce a un refcount underflow en algunas condiciones:<br /> ------------[ corte aquí ]------------<br /> refcount_t: underflow; uso después de liberación.<br /> ADVERTENCIA: CPU: 2 PID: 1694 en lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0<br /> [...]<br /> mlx5e_psp_unregister+0x26/0x50 [mlx5_core]<br /> mlx5e_nic_cleanup+0x26/0x90 [mlx5_core]<br /> mlx5e_remove+0xe6/0x1f0 [mlx5_core]<br /> auxiliary_bus_remove+0x18/0x30<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> mlx5_rescan_drivers_locked+0xbc/0x2a0 [mlx5_core]<br /> [...]<br /> <br /> No eliminar directamente psp de la ruta _mlx5e_remove, la limpieza de PSP ocurre como parte de la limpieza del perfil.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sched/deadline: solo establecer free_cpus para runqueues en línea<br /> <br /> El commit 16b269436b72 (&amp;#39;sched/deadline: Modificar cpudl::free_cpus para reflejar rd-&amp;gt;online&amp;#39;) introdujo las funciones cpudl_set/clear_freecpu para permitir que la máscara cpu_dl::free_cpus fuera manipulada por las devoluciones de llamada rq_on/offline de la clase de planificador de plazo para que la máscara también reflejara este estado.<br /> <br /> El commit 9659e1eeee28 (&amp;#39;sched/deadline: Eliminar cpu_active_mask de cpudl_find()&amp;#39;) eliminó la comprobación de la cpu_active_mask para ahorrar algo de procesamiento bajo la premisa de que la máscara cpudl::free_cpus ya reflejaba el estado en línea del runqueue.<br /> <br /> Desafortunadamente, hay casos en los que es posible que la función cpudl_clear establezca el bit free_cpus para una CPU cuando el runqueue de plazo está fuera de línea. Cuando esto ocurre mientras una CPU está conectada al dominio raíz predeterminado, el indicador puede retener el estado incorrecto después de que la CPU haya sido desconectada. Más tarde, una CPU diferente que está en transición a través del dominio raíz predeterminado puede empujar una tarea de plazo a la CPU apagada cuando cpudl_find ve que su bit free_cpus está establecido. Si esto sucede, la tarea no tendrá la oportunidad de ejecutarse.<br /> <br /> Un ejemplo se describe aquí:<br /> https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com<br /> <br /> Otro ocurre cuando la última tarea de plazo es migrada de una CPU que tiene un runqueue fuera de línea. El miembro dequeue_task de la clase de planificador de plazo eventualmente llamará a cpudl_clear y establecerá el bit free_cpus para la CPU.<br /> <br /> Este commit modifica la función cpudl_clear para que sea consciente del estado en línea del runqueue de plazo para que la máscara free_cpus pueda ser actualizada apropiadamente.<br /> <br /> Ya no es necesario gestionar la máscara fuera de las funciones cpudl_set/clear, por lo que las funciones cpudl_set/clear_freecpu son eliminadas. Además, dado que la máscara free_cpus ahora solo se actualiza bajo el bloqueo cpudl, el código fue cambiado para usar las funciones no atómicas __cpumask.