CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52623 – SUNRPC: Fix a suspicious RCU usage warning
https://notcve.org/view.php?id=CVE-2023-52623
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a suspicious RCU usage warning I received the following warning while running cthon against an ontap server running pNFS: [ 57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [ 57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ? • https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6 https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7 https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56 https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0 https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6 https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52622 – ext4: avoid online resizing failures due to oversized flex bg
https://notcve.org/view.php?id=CVE-2023-52622
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evita fallos de cambio de tamaño en línea debido a flex bg sobredimensionado Cuando redimensionamos en línea un sistema de archivos ext4 con un flexbg_size sobredimensionado, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G se activa el siguiente WARN_ON: ===================================== ============================== ADVERTENCIA: CPU: 0 PID: 427 en mm/page_alloc.c:4402 __alloc_pages+0x411/ 0x550 Módulos vinculados en: sg(E) CPU: 0 PID: 427 Comm: resize2fs Contaminado: GE 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Seguimiento de llamadas: __kmalloc_large_node+0xa2/0x200 __kmalloc+ 0x16e/0x290 text4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 text4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ======== =============== ============================================ Esto se debe a que flexbg_size también lo es grande y el tamaño de la matriz new_group_data que se asignará excede MAX_ORDER. • https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644 https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07 https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8 https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90 https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954 https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2 https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea • CWE-131: Incorrect Calculation of Buffer Size •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52621 – bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
https://notcve.org/view.php?id=CVE-2023-52621
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? • https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3 https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304 https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d https://access.redhat.com/security/cve/CVE-2023-52621 https://bugzilla.redhat.com/show_bug.cgi?id=2271690 • CWE-413: Improper Resource Locking •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26645 – tracing: Ensure visibility when inserting an element into tracing_map
https://notcve.org/view.php?id=CVE-2024-26645
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: garantiza la visibilidad al insertar un elemento en tracing_map La ejecución de los siguientes dos comandos en paralelo en una máquina multiprocesador AArch64 puede producir esporádicamente una advertencia inesperada sobre entradas de histograma duplicadas: $ while true ; hacer echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ estrés-ng --sysbadaddr $(nproc) La advertencia tiene el siguiente aspecto: [ 2911.172474] ------------[ cortar aquí ]------------ [ 2911.173111] Duplicados detectados: 1 [2911.173574] ADVERTENCIA: CPU: 2 PID: 12247 en kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [2911.174702] Módulos vinculados en: iscsi_ibft(E) iscsi_boot_sy sfs(E) rfkill(E ) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) botón(E) fusible(E) efi_pstore(E) ip_tables(E) x_tables (E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E ) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth (E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Módulos contaminados descargados: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: cargado Contaminado: GE 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [2911.182398] Nombre de hardware: Amazon EC2 c7g.8xlarge/, BIOS 1.0 1/11/2018 [2911.183208] pstate: 6140 0005 (nZCv daif +PAN -UAO -TCO +DIT - SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.18 5750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 00000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.1883 10] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a151 34b8 [2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 00 0000000017ffe8 x7: c0000000fffeffff x6: 000000000057ffa8 [2911.192554] x5: ffff0012f6c24ec0 x4: 00000000000000000 x3: ffff2e5b72b5d000 [2911.193 404] x2: 0000000000000000 x1: 0000000000000000 x0 : ffff0003ff254480 [2911.194259] Rastreo de llamadas: [2911.194626] tracing_map_sort_entries+0x3e0/0x408 [2911.195220] hist_show+0x124/0x800 [2911.195692] seq_read_iter+0x1d4 /0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078 ] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0x f8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- El problema parece deberse a la reordenación de la CPU de escrituras emitidas desde __tracing_map_insert(). La comprobación de la presencia de un elemento con una clave determinada en esta función es: val = READ_ONCE(entry->val); if (val && llaves_match(key, val->key, map->key_size)) ... La escritura de una nueva entrada es: elt = get_free_elt(map); memcpy(elt->clave, clave, mapa->key_size); entrada->val = elt; El "memcpy(elt->key, key, map->key_size);" y "entrada->val = elt;" Las tiendas pueden volverse visibles en orden inverso en otra CPU.---truncada--- • https://git.kernel.org/stable/c/c193707dde77ace92a649cd59a17e105e2fbeaef https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860 https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177 https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7 https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac941223 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26644 – btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
https://notcve.org/view.php?id=CVE-2024-26644
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? • https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464 https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256 https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •