CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47128 – bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks
https://notcve.org/view.php?id=CVE-2021-47128
In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit: 1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0]. 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like: rq_lock(rq) -> -------------------------+ trace_sched_switch() -> | bpf_prog_xyz() -> +-> deadlock selinux_lockdown() -> | audit_log_end() -> | wake_up_interruptible() -> | try_to_wake_up() -> | rq_lock(rq) --------------+ What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. • https://git.kernel.org/stable/c/59438b46471ae6cdfb761afc8c9beaf1e428a331 https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47127 – ice: track AF_XDP ZC enabled queues in bitmap
https://notcve.org/view.php?id=CVE-2021-47127
In the Linux kernel, the following vulnerability has been resolved: ice: track AF_XDP ZC enabled queues in bitmap Commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure") silently introduced a regression and broke the Tx side of AF_XDP in copy mode. xsk_pool on ice_ring is set only based on the existence of the XDP prog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed. That is not something that should happen for copy mode as it should use the regular data path ice_clean_tx_irq. This results in a following splat when xdpsock is run in txonly or l2fwd scenarios in copy mode: <snip> [ 106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 106.057269] #PF: supervisor read access in kernel mode [ 106.062493] #PF: error_code(0x0000) - not-present page [ 106.067709] PGD 0 P4D 0 [ 106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45 [ 106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50 [ 106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00 [ 106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206 [ 106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800 [ 106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800 [ 106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800 [ 106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff [ 106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018 [ 106.157117] FS: 0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000 [ 106.165332] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0 [ 106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 106.192898] PKRU: 55555554 [ 106.195653] Call Trace: [ 106.198143] <IRQ> [ 106.200196] ice_clean_tx_irq_zc+0x183/0x2a0 [ice] [ 106.205087] ice_napi_poll+0x3e/0x590 [ice] [ 106.209356] __napi_poll+0x2a/0x160 [ 106.212911] net_rx_action+0xd6/0x200 [ 106.216634] __do_softirq+0xbf/0x29b [ 106.220274] irq_exit_rcu+0x88/0xc0 [ 106.223819] common_interrupt+0x7b/0xa0 [ 106.227719] </IRQ> [ 106.229857] asm_common_interrupt+0x1e/0x40 </snip> Fix this by introducing the bitmap of queues that are zero-copy enabled, where each bit, corresponding to a queue id that xsk pool is being configured on, will be set/cleared within ice_xsk_pool_{en,dis}able and checked within ice_xsk_pool(). The latter is a function used for deciding which napi poll routine is executed. Idea is being taken from our other drivers such as i40e and ixgbe. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: rastrear colas habilitadas para AF_XDP ZC en mapa de bits. El commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI Structure") introdujo silenciosamente una regresión y rompió el lado Tx de AF_XDP en modo de copia. xsk_pool en ice_ring se configura únicamente en función de la existencia del programa XDP en la VSI, que a su vez selecciona ice_clean_tx_irq_zc para ejecutarse. Eso no es algo que debería suceder en el modo de copia, ya que debería usar la ruta de datos normal ice_clean_tx_irq. • https://git.kernel.org/stable/c/c7a219048e459cf99c6fec0f7c1e42414e9e6202 https://git.kernel.org/stable/c/1d34fa4fcf06649036ba0c97854fcf7a741ee18c https://git.kernel.org/stable/c/e102db780e1c14f10c70dafa7684af22a745b51d •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47126 – ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions
https://notcve.org/view.php?id=CVE-2021-47126
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions Reported by syzbot: HEAD commit: 90c911ad Merge tag 'fixes' of git://git.kernel.org/pub/scm.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master dashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7 compiler: Debian clang version 11.0.1-2 ================================================================== BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] BUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 Read of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760 CPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x202/0x31e lib/dump_stack.c:120 print_address_description+0x5f/0x3b0 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report+0x15c/0x200 mm/kasan/report.c:416 fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline] fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536 fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174 rcu_do_batch kernel/rcu/tree.c:2559 [inline] rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794 __do_softirq+0x372/0x7a6 kernel/softirq.c:345 invoke_softirq kernel/softirq.c:221 [inline] __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422 irq_exit_rcu+0x5/0x20 kernel/softirq.c:434 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632 RIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515 Code: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d RSP: 0018:ffffc90009e06560 EFLAGS: 00000206 RAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1 R10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4 rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267 rcu_read_lock include/linux/rcupdate.h:656 [inline] ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231 ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212 ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379 ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982 ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238 ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638 ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848 ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900 ext4_append+0x1a4/0x360 fs/ext4/namei.c:67 ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768 ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814 vfs_mkdir+0x45b/0x640 fs/namei.c:3819 ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline] ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146 ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193 ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788 ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355 ovl_get_workdir fs/overlayfs/super.c:1492 [inline] ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035 mount_nodev+0x52/0xe0 fs/super.c:1413 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2903 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3233 do_mount fs/namespace.c:3246 [inline] __do_sys_mount fs/namespace.c:3454 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: Corrección KASAN: slab-out-of-bounds Leer en fib6_nh_flush_exceptions Reportado por syzbot: HEAD commit: 90c911ad Merge tag 'fixes' de git://git.kernel.org /pub/scm.. árbol git: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git enlace del panel maestro: https://syzkaller.appspot.com/bug? extid=123aa35098fd3c000eb7 compilador: Debian clang versión 11.0.1-2 ===================================== ============================= ERROR: KASAN: losa fuera de los límites en fib6_nh_get_excptn_bucket net/ipv6/route.c: 1604 [en línea] ERROR: KASAN: losa fuera de los límites en fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 Lectura de tamaño 8 en la dirección ffff8880145c78f8 por la tarea syz-executor.4/17760 CPU: 0 PID : 17760 Comm: syz-executor.4 No contaminado 5.12.0-rc8-syzkaller #0 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack+0x202/0x31e lib/dump_stack.c:120 print_address_description +0x5f/0x3b0 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [en línea] kasan_report+0x15c/0x200 mm/kasan/report.c:416 fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [en línea] fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732 fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536 fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174 rcu_do_batch kernel /rcu/ tree.c:2559 [en línea] rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794 __do_softirq+0x372/0x7a6 kernel/softirq.c:345 invoke_softirq kernel/softirq.c:221 [en línea] __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422 irq_exit_rcu+0x5/0x20 kernel/softirq.c:434 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/ include/asm/idtentry.h:632 RIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515 Código: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d RSP: 0018:ffffc90009e06560 EFLAGS: 00000206 RAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000 000000 RBP: ffffc90009e066e0 R08: dffffc0000000000 R09: ffffbfff1f992b1 R10: ffffbfff1f992b1 R11: 00000000000000000 R12: 0000000000000000 R13: dffff c0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4 rcu_lock_acquire+ 0x2a/0x30 include/linux/rcupdate.h:267 rcu_read_lock include/linux/rcupdate.h:656 [en línea] ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231 text4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc. c:2212 ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379 ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982 ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c :4238 text4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638 text4_getblk+0x187/0x6c0 fs/ext4/inode.c:848 text4_bread+0x2a/0x1c0 fs/ext4/inode.c:900 text4_append+0x1a4/0x360 fs/ext4/namei.c: 67 ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768 ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814 vfs_mkdir+0x45b/0x640 fs/namei.c:3819 ovl_do_mkdir fs/overlayfs/over layfs.h: 161 [en línea] ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146 ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193 ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788 ovl_make_workdir+0 fijo/ 0x1140 fs/overlayfs/super.c:1355 ovl_get_workdir fs/overlayfs/super.c:1492 [en línea] ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035 mount_nodev+0x52/0xe0 fs/super.c:1413 Legacy_get_tree +0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2903 [en línea] path_mount+0x196f/0x2be0 fs/namespace.c:3233 do_mount fs/namespace .c:3246 [en línea]---truncado--- • https://git.kernel.org/stable/c/f88d8ea67fbdbac7a64bfa6ed9a2ba27bb822f74 https://git.kernel.org/stable/c/7ba7fa78a92dc410b6f93ed73075ab669c3a0b59 https://git.kernel.org/stable/c/09870235827451409ff546b073d754a19fd17e2e https://git.kernel.org/stable/c/0a462e25ef0f7ab305081a08d435bbd1f13c0a94 https://git.kernel.org/stable/c/821bbf79fe46a8b1d18aa456e8ed0a3c208c3754 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47125 – sch_htb: fix refcount leak in htb_parent_to_leaf_offload
https://notcve.org/view.php?id=CVE-2021-47125
In the Linux kernel, the following vulnerability has been resolved: sch_htb: fix refcount leak in htb_parent_to_leaf_offload The commit ae81feb7338c ("sch_htb: fix null pointer dereference on a null new_q") fixes a NULL pointer dereference bug, but it is not correct. Because htb_graft_helper properly handles the case when new_q is NULL, and after the previous patch by skipping this call which creates an inconsistency : dev_queue->qdisc will still point to the old qdisc, but cl->parent->leaf.q will point to the new one (which will be noop_qdisc, because new_q was NULL). The code is based on an assumption that these two pointers are the same, so it can lead to refcount leaks. The correct fix is to add a NULL pointer check to protect qdisc_refcount_inc inside htb_parent_to_leaf_offload. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_htb: corrige la fuga de recuento en htb_parent_to_leaf_offload el commit ae81feb7338c ("sch_htb: corrige la desreferencia del puntero nulo en un new_q nulo") corrige un error de desreferencia del puntero NULL, pero no es correcto. Debido a que htb_graft_helper maneja adecuadamente el caso cuando new_q es NULL, y después del parche anterior al omitir esta llamada, se crea una inconsistencia: dev_queue->qdisc seguirá apuntando a la qdisc anterior, pero cl->parent->leaf.q apuntará a el nuevo (que será noop_qdisc, porque new_q era NULL). El código se basa en la suposición de que estos dos indicadores son iguales, por lo que puede provocar fugas de recuento. La solución correcta es agregar una verificación de puntero NULL para proteger qdisc_refcount_inc dentro de htb_parent_to_leaf_offload. • https://git.kernel.org/stable/c/ae81feb7338c89cee4e6aa0424bdab2ce2b52da2 https://git.kernel.org/stable/c/2411c02d03892a5057499f8102d0cc1e0f852416 https://git.kernel.org/stable/c/944d671d5faa0d78980a3da5c0f04960ef1ad893 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47124 – io_uring: fix link timeout refs
https://notcve.org/view.php?id=CVE-2021-47124
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix link timeout refs WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] io_put_req fs/io_uring.c:2140 [inline] io_queue_linked_timeout fs/io_uring.c:6300 [inline] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [inline] io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [inline] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() should put only one reference of the linked timeout request, however in case of racing with the master request's completion first io_req_complete() puts one and then io_put_req_deferred() is called. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige las referencias de tiempo de espera del enlace ADVERTENCIA: CPU: 0 PID: 10242 en lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010: refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Seguimiento de llamadas: __refcount_sub_and_test include/linux/refcount.h:283 [en línea] __refcount_dec_and_test include/linux/refcount.h:315 [en línea] refcount_dec_and_test include/linux/refcount.h: 333 [en línea] io_put_req fs/io_uring.c:2140 [en línea] io_queue_linked_timeout fs/io_uring.c:6300 [en línea] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [en línea] io_submit _sqes +0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [en línea] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() debe poner solo una referencia de la solicitud de tiempo de espera vinculada, sin embargo en En el caso de competir con la finalización de la solicitud maestra, primero io_req_complete() coloca uno y luego se llama a io_put_req_deferred(). • https://git.kernel.org/stable/c/1c20e9040f49687ba2ccc2ffd4411351a6c2ebff https://git.kernel.org/stable/c/9ae1f8dd372e0e4c020b345cf9e09f519265e981 https://git.kernel.org/stable/c/567c81912cec641db75ac6cb64c63f8367c97d19 https://git.kernel.org/stable/c/0b2a990e5d2f76d020cb840c456e6ec5f0c27530 https://git.kernel.org/stable/c/6f5d7a45f58d3abe3a936de1441b8d6318f978ff https://git.kernel.org/stable/c/876808dba2ff7509bdd7f230c4f374a0caf4f410 https://git.kernel.org/stable/c/ff4a96ba5c8f9b266706280ff8021d2ef3f17e86 https://git.kernel.org/stable/c/a298232ee6b9a1d5d732aa497ff8be0d4 •