CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26597 – net: qualcomm: rmnet: fix global oob in rmnet_policy
https://notcve.org/view.php?id=CVE-2024-26597
In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix global oob in rmnet_policy The variable rmnet_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below: ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK> The buggy address belongs to the variable: rmnet_policy+0x30/0xe0 The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qualcomm: rmnet: fix global oob in rmnet_policy La variable rmnet_link_ops asigna un maxtype *más grande* que conduce a una lectura global fuera de los límites al analizar los atributos de netlink. Vea el seguimiento del error a continuación: =============================================== ===================== ERROR: KASAN: global-fuera de los límites en validar_nla lib/nlattr.c:386 [en línea] ERROR: KASAN: global- fuera de los límites en __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Lectura de tamaño 1 en addr ffffffff92c438d0 por tarea syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Contaminado: GN 6.1.0 #3 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl +0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [en línea] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c :495 validar_nla lib/nlattr.c:386 [en línea] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [en línea] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/ enlace de red /af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/ socket.c:714 [en línea] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3 /0x1c0 neto /socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Código: 2 8 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 ffff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf21 9ff80 RCX: 00007fdcf2072359 RDX: 00000000000000000 RSI: 0000000020000200 RDI: 00000000000000003 RBP: 00007fdcf20bd493 R08: 000000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R 15: 0000000000022000 La dirección con errores pertenece a la variable: rmnet_policy+0x30/0xe0 La dirección con errores pertenece a la página física: página:0000000065bdeb3c refcount:1 mapcount:0 mapeo:0000000000000000 índice:0x0 pfn:0x155243 banderas: 0x200000000001000(reservado|nodo=0|zona=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección del error: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c438 80: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 Según según el comentario de `nla_parse_nested_deprecated`, el tipo máximo debe ser len (matriz de destino) - 1. • https://git.kernel.org/stable/c/14452ca3b5ce304fb2fea96dbc9ca1e4e7978551 https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590 https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5 https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447 https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468 https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534 https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b091534 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26595 – mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
https://notcve.org/view.php?id=CVE-2024-26595
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la desreferencia del puntero NULL en la ruta de error Al llamar a mlxsw_sp_acl_tcam_region_destroy() desde una ruta de error después de no poder adjuntar la región a un grupo de ACL, alcanzamos una desreferencia del puntero NULL al 'región->grupo->tcam' [1]. Solucione recuperando el puntero 'tcam' usando mlxsw_sp_acl_to_tcam(). [1] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Seguimiento de llamadas: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0 x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b 0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b A flaw was found in the Linux kernel, where a faulty error handler in the driver for certain Mellanox hardware could lead to a null pointer reference. This issue affects system stability. • https://git.kernel.org/stable/c/22a677661f5624539d394f681276171f92d714df https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39 https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 https://access.redhat.com/security/cve/CVE-2024-26595 https://bugzilla.redhat.com/show_bug.cgi?id=2265799 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52464 – EDAC/thunderx: Fix possible out-of-bounds string access
https://notcve.org/view.php?id=CVE-2023-52464
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/thunderx: corrige un posible acceso a cadenas fuera de los límites Al habilitar -Wstringop-overflow globalmente se expone una advertencia para un error común en el uso de strncat(): drivers/edac/ thunderx_edac.c: En la función 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' el límite especificado 1024 es igual al tamaño de destino [-Werror=stringop-overflow=] 1136 | strncat(msj, otro, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msj, otro, OCX_MESSAGE_SIZE); ... 1150 | strncat(msj, otro, OCX_MESSAGE_SIZE); ... Aparentemente, el autor de este controlador esperaba que strncat() se comportara de la manera que lo hace strlcat(), que utiliza el tamaño del búfer de destino como tercer argumento en lugar de la longitud del búfer de origen. El resultado es que no se comprueba el tamaño del búfer asignado. Cámbielo a strlcat(). • https://git.kernel.org/stable/c/41003396f932d7f027725c7acebb6a7caa41dc3e https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601 https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6 https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21 https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398 https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057 https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc4 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-805: Buffer Access with Incorrect Length Value •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52463 – efivarfs: force RO when remounting if SetVariable is not supported
https://notcve.org/view.php?id=CVE-2023-52463
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? • https://git.kernel.org/stable/c/f88814cc2578c121e6edef686365036db72af0ed https://git.kernel.org/stable/c/552952e51fad35670459674bcb8a03bd96fe4646 https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8 https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826 https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737 https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548 https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e627 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52462 – bpf: fix check for attempt to corrupt spilled pointer
https://notcve.org/view.php?id=CVE-2023-52462
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: revisión de corrección para intentar dañar el puntero derramado Cuando el registro se derrama en una pila como un registro de 1/2/4 bytes, configuramos slot_type[BPF_REG_SIZE - 1] (más potencialmente algunos más debajo de él, dependiendo del tamaño real del derrame). Entonces, para verificar si alguna ranura de la pila se ha desbordado, debemos consultar slot_type[7], no slot_type[0]. Para evitar la necesidad de recordar y volver a verificar esto en el futuro, simplemente use el asistente is_spilled_reg(). • https://git.kernel.org/stable/c/cdd73a5ed0840da88a3b9ad353f568e6f156d417 https://git.kernel.org/stable/c/07c286c10a9cedbd71f20269ff3a4e73d9aab2fe https://git.kernel.org/stable/c/27113c59b6d0a587b29ae72d4ff3f832f58b0651 https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104 https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174 https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a •