"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\nNotethatweneedtomoveput_net()fromcifs_put_tcp_session()to\nclean_demultiplex_info();otherwise,__sock_create()stillcouldtoucha\nfreednetnswhilecifsdtriestoreconnectfromcifs_demultiplex_thread().\n\nAlso,maybe_get_net()cannotbeputjustbefore__sock_create()because\nthecodeisnotunderRCUandthereisasmallchancethatthesame\naddresshappenedtobereallocatedtoanothernetns.\n\n[0]:\nCIFS:VFS:\\\\XXXXXXXXXXXhasnotrespondedin15seconds.Reconnecting...\nCIFS:Serverclosefailed4times,givingup\nUnabletohandlekernelpagingrequestatvirtualaddress14de99e461f84a07\nMemabortinfo:\nESR=0x0000000096000004\nEC=0x25:DABT(currentEL),IL=32bits\nSET=0,FnV=0\nEA=0,S1PTW=0\nFSC=0x04:level0translationfault\nDataabortinfo:\nISV=0,ISS=0x00000004\nCM=0,WnR=0\n[14de99e461f84a07]addressbetweenuserandkerneladdressranges\nInternalerror:Oops:0000000096000004[#1]SMP\nModuleslinkedin:cls_bpfsch_ingressnls_utf8cifscifs_arc4cifs_md4dns_resolvertcp_diaginet_diagvethxt_statext_connmarknf_conntrack_netlinkxt_natxt_statisticxt_MASQUERADExt_markxt_addrtypeipt_REJECTnf_reject_ipv4nft_chain_natnf_natxt_conntracknf_conntracknf_defrag_ipv6nf_defrag_ipv4xt_commentnft_compatnf_tablesnfnetlinkoverlaynls_asciinls_cp437sunrpcvfatfataes_ce_blkaes_ce_cipherghash_cesm4_ce_ciphersm4sm3_cesm3sha3_cesha512_cesha512_arm64sha1_ceenabuttonsch_fq_codelloopfuseconfigfsdmi_sysfssha2_cesha256_arm64dm_mirrordm_region_hashdm_logdm_moddaxefivarfs\nCPU:5PID:2690970Comm:cifsdNottainted6.1.103-109.184.amzn2023.aarch64#1\nHardwarename:AmazonEC2r7g.4xlarge/,BIOS1.011/1/2018\npstate:00400005(nzcvdaif+PAN-UAO-TCO-DIT-SSBSBTYPE=--)\npc:fib_rules_lookup+0x44/0x238\nlr:__fib_lookup+0x64/0xbc\nsp:ffff8000265db790\nx29:ffff8000265db790x28:0000000000000000x27:000000000000bd01\nx26:0000000000000000x25:ffff000b4baf8000x24:ffff00047b5e4580\nx23:ffff8000265db7e0x22:0000000000000000x21:ffff00047b5e4500\nx20:ffff0010e3f694f8x19:14de99e461f849f7x18:0000000000000000\nx17:0000000000000000x16:0000000000000000x15:0000000000000000\nx14:0000000000000000x13:0000000000000000x12:3f92800abd010002\nx11:0000000000000001x10:ffff0010e3f69420x9:ffff800008a6f294\nx8:0000000000000000x7:0000000000000006x6:0000000000000000\nx5:0000000000000001x4:ffff001924354280x3:ffff8000265db7e0\nx2:0000000000000000x1:ffff0010e3f694f8x0:ffff00047b5e4500\nCalltrace:\nfib_rules_lookup+0x44/0x238\n__fib_lookup+0x64/0xbc\nip_route_output_key_hash_rcu+0x2c4/0x398\nip_route_output_key_hash+0x60/0x8c\ntcp_v4_connect+0x290/0x488\n__inet_stream_connect+0x108/0x3d0\ninet_stream_connect+0x50/0x78\nkernel_connect+0x6c/0xac\ngeneric_ip_conne\n---trunca
},
{
"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().\").Tengaencuentaquedebemosmoverput_net()decifs_put_tcp_session()aclean_demultiplex_info();delocontrario,__sock_create()a\u00fanpodr\u00edatocarunnetnsliberadomientrascifsdintentareconectarsedesdecifs_demultiplex_thread().Adem\u00e1s,maybe_get_net()nosepuedecolocarjustoantesde__sock_create()porqueelc\u00f3digonoest\u00e1bajoRCUyexisteunapeque\u00f1aposibilidaddequelamismadirecci\u00f3nsehayareasignadoaotronetns.[0]:CIFS:VFS:\\\\XXXXXXXXXXXnoharespondidoen15segundos.Reconectando...CIFS:Serverclosefall\u00f34veces,abandonandoNosepuedemanejarlasolicituddepaginaci\u00f3ndeln\u00facleoenladirecci\u00f3nvirtual14de99e461f84a07Informaci\u00f3ndeabortodememoria:ESR=0x0000000096000004EC=0x25:DABT(ELactual),IL=32bitsSET=0,FnV=0EA=0,S1PTW=0FSC=0x04:errordetraducci\u00f3ndenivel0Informaci\u00f3ndeabortodedatos:ISV=0,ISS=0x00000004CM=0,WnR=0[14de99e461f84a07]direcci\u00f3nentrerangosdedireccionesdeusuarioyn\u00facleoErrorinterno:Oops:0000000096000004[#1]M\u00f3dulosSMPvinculadosen:cls_bpfsch_ingressnls_utf8cifscifs_arc4cifs_md4dns_resolvertcp_diaginet_diagvethxt_estadoxt_connmarknf_conntrack_netlinkxt_natxt_estad\u00edsticaxt_MASQUERADExt_marcaxt_tipo_direcci\u00f3nipt_REJECTnf_reject_ipv4nft_chain_natnf_natxt_conntracknf_conntracknf_defrag_ipv6nf_defrag_ipv4xt_commentnft_compatnf_tablessuperposici\u00f3nnfnetlinknls_asciinls_cp437sunrpcvfatfataes_ce_blkaes_ce_cipherghash_cesm4_ce_ciphersm4sm3_cesm3sha3_cesha512_cesha512_arm64sha1_ceenabot\u00f3nsch_fq_codelbuclefusibleconfigfsdmi_sysfssha2_cesha256_arm64dm_mirrordm_region_hashdm_logdm_moddaxefivarfsCPU:5PID:2690970Comm:cifsdNocontaminado6.1.103-109.184.amzn2023.aarch64#1Nombredelhardware:AmazonEC2r7g.4xlarge/,BIOS1.01/11/2018pstate:00400005(nzcvdaif+PAN-UAO-TCO-DIT-SSBSBTYPE=--)pc:fib_rules_lookup+0x44/0x238lr:__fib_lookup+0x64/0xbcsp:ffff8000265db790x29:ffff8000265db790x28:0000000000000000x27:0000000000000bd01x26:0000000000000000x25:ffff000b4baf8000x24:ffff00047b5e4580x23:ffff8000265db7e0x22:0000000000000000x21:ffff00047b5e4500x20:ffff0010e3f694f8x19:14de99e461f849f7x18:0000000000000000x17:0000000000000000x16:0000000000000000x15:0000000000000000x14:0000000000000000x13:0000000000000000x12:3f92800abd010002x11:0000000000000001x10:ffff0010e3f69420x9:ffff800008a6f294x8:0000000000000000x7:00000000000000006x6:0000000000000000x5:00000000000000001x4:ffff001924354