CVE-2024-53095

{"id": "CVE-2024-53095", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "published": "2024-11-21T19:15:12.867", "references": [{"url": "https://git.kernel.org/stable/c/c7f9282fc27fc36dbaffc8527c723de264a132f8", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e8c71494181153a134c96da28766a57bd1eac8cb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/ef7134c7fc48e1441b398e55a862232868a6f0a7", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "description": [{"lang": "en", "value": "CWE-416"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free of network namespace.\n\nRecently, we got a customer report that CIFS triggers oops while\nreconnecting to a server. [0]\n\nThe workload runs on Kubernetes, and some pods mount CIFS servers\nin non-root network namespaces. The problem rarely happened, but\nit was always while the pod was dying.\n\nThe root cause is wrong reference counting for network namespace.\n\nCIFS uses kernel sockets, which do not hold refcnt of the netns that\nthe socket belongs to. That means CIFS must ensure the socket is\nalways freed before its netns; otherwise, use-after-free happens.\n\nThe repro steps are roughly:\n\n 1. mount CIFS in a non-root netns\n 2. drop packets from the netns\n 3. destroy the netns\n 4. unmount CIFS\n\nWe can reproduce the issue quickly with the script [1] below and see\nthe splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.\n\nWhen the socket is TCP, it is hard to guarantee the netns lifetime\nwithout holding refcnt due to async timers.\n\nLet's hold netns refcnt for each socket as done for SMC in commit\n9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\").\n\nNote that we need to move put_net() from cifs_put_tcp_session() to\nclean_demultiplex_info(); otherwise, __sock_create() still could touch a\nfreed netns while cifsd tries to reconnect from cifs_demultiplex_thread().\n\nAlso, maybe_get_net() cannot be put just before __sock_create() because\nthe code is not under RCU and there is a small chance that the same\naddress happened to be reallocated to another netns.\n\n[0]:\nCIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...\nCIFS: Serverclose failed 4 times, giving up\nUnable to handle kernel paging request at virtual address 14de99e461f84a07\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004\n CM = 0, WnR = 0\n[14de99e461f84a07] address between user and kernel address ranges\nInternal error: Oops: 0000000096000004 [#1] SMP\nModules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs\nCPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1\nHardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018\npstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : fib_rules_lookup+0x44/0x238\nlr : __fib_lookup+0x64/0xbc\nsp : ffff8000265db790\nx29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01\nx26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580\nx23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500\nx20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002\nx11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294\nx8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0\nx2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500\nCall trace:\n fib_rules_lookup+0x44/0x238\n __fib_lookup+0x64/0xbc\n ip_route_output_key_hash_rcu+0x2c4/0x398\n ip_route_output_key_hash+0x60/0x8c\n tcp_v4_connect+0x290/0x488\n __inet_stream_connect+0x108/0x3d0\n inet_stream_connect+0x50/0x78\n kernel_connect+0x6c/0xac\n generic_ip_conne\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: Fix use-after-free of network namespace. Recientemente, recibimos un informe de un cliente que indica que CIFS desencadena errores al reconectarse a un servidor. [0] La carga de trabajo se ejecuta en Kubernetes y algunos pods montan servidores CIFS en espacios de nombres de red que no son ra\u00edz. El problema rara vez suced\u00eda, pero siempre suced\u00eda mientras el pod se estaba muriendo. La causa ra\u00edz es un recuento de referencias incorrecto para el espacio de nombres de red. CIFS usa sockets de kernel, que no contienen refcnt de las netn a las que pertenece el socket. Eso significa que CIFS debe asegurarse de que el socket siempre se libere antes que sus netn; de lo contrario, se produce el use after free. Los pasos de reproducci\u00f3n son, a grandes rasgos: 1. montar CIFS en una red no ra\u00edz 2. descartar paquetes de la red 3. destruir la red 4. desmontar CIFS Podemos reproducir el problema r\u00e1pidamente con el script [1] a continuaci\u00f3n y ver el splat [2] si CONFIG_NET_NS_REFCNT_TRACKER est\u00e1 habilitado. Cuando el socket es TCP, es dif\u00edcil garantizar la duraci\u00f3n de la red sin mantener refcnt debido a los temporizadores as\u00edncronos. Mantengamos netns refcnt para cada socket como se hizo para SMC en el commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Tenga en cuenta que debemos mover put_net() de cifs_put_tcp_session() a clean_demultiplex_info(); de lo contrario, __sock_create() a\u00fan podr\u00eda tocar un netns liberado mientras cifsd intenta reconectarse desde cifs_demultiplex_thread(). Adem\u00e1s, maybe_get_net() no se puede colocar justo antes de __sock_create() porque el c\u00f3digo no est\u00e1 bajo RCU y existe una peque\u00f1a posibilidad de que la misma direcci\u00f3n se haya reasignado a otro netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX no ha respondido en 15 segundos. Reconectando... CIFS: Serverclose fall\u00f3 4 veces, abandonando No se puede manejar la solicitud de paginaci\u00f3n del n\u00facleo en la direcci\u00f3n virtual 14de99e461f84a07 Informaci\u00f3n de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducci\u00f3n de nivel 0 Informaci\u00f3n de aborto de datos: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] direcci\u00f3n entre rangos de direcciones de usuario y n\u00facleo Error interno: Oops: 0000000096000004 [#1] M\u00f3dulos SMP vinculados en: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_estado xt_connmark nf_conntrack_netlink xt_nat xt_estad\u00edstica xt_MASQUERADE xt_marca xt_tipo_direcci\u00f3n ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables superposici\u00f3n nfnetlink nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena bot\u00f3n sch_fq_codel bucle fusible configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd No contaminado 6.1.103-109.184.amzn2023.aarch64 #1 Nombre del hardware: Amazon EC2 r7g.4xlarge/, BIOS 1.0 1/11/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 0000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 00000000000000006 x6 : 0000000000000000 x5 : 00000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 ---truncada---"}], "lastModified": "2024-12-11T15:15:17.940", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}