ALT-BU-2023-2724-4
Branch p9 update bulletin.
Package kernel-image-un-def updated to version 5.10.170-alt1 for branch p9 in task 315796.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2022-07509
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ и повысить свои привилегии
Modified: 2025-08-19
BDU:2023-01571
Уязвимость функции tcf_exts_exec() фильтра индексирования системы контроля трафика tcindex ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-30
BDU:2023-02532
Уязвимость функции _copy_from_user() в модуле lib/usercopy.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
BDU:2024-10366
Уязвимость компонента mmc_spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10367
Уязвимость компонентов sched/psi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10369
Уязвимость компонента hda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10372
Уязвимость компонента sdio ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2025-10566
Уязвимость функции ovs_meter_cmd_set() модуля net/openvswitch/meter.c поддержки маршрутизаторов Open vSwitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-14291
Уязвимость функции aio_ring_mremap() модуля fs/aio.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14587
Уязвимость функции nilfs_ioctl_set_alloc_range() модуля fs/nilfs2/ioctl.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15324
Уязвимость функции kalmia_send_init_packet() модуля drivers/net/usb/kalmia.c - драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02573
Уязвимость функции nft_tproxy_dump() в модуле net/netfilter/nft_tproxy.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06000
Уязвимость функции ext4_sb_release() модуля fs/ext4/sysfs.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
CVE-2022-2196
A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn't need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5
- https://kernel.dance/#2e7eab81425a
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5
- https://kernel.dance/#2e7eab81425a
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230223-0002/
Modified: 2025-11-14
CVE-2022-50001
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output.
- https://git.kernel.org/stable/c/0b21edf4cc13516716848e0a4fdf726aa2a62cd9
- https://git.kernel.org/stable/c/18bbc3213383a82b05383827f4b1b882e3f0a5a5
- https://git.kernel.org/stable/c/343fed6b0daeb528ae5c9d4d84d9ff763ac95619
- https://git.kernel.org/stable/c/83ef55c4281f1b4c6bd4457c2e96ccd1c9e80200
- https://git.kernel.org/stable/c/9a1d92cbeac3335fee99fa865b8c5b0f2e71a8f7
- https://git.kernel.org/stable/c/eaba3f9b672c3a3f820da8ee9584b9520674eafa
Modified: 2024-11-21
CVE-2023-0459
Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the "access_ok" check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information. We recommend upgrading beyond commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47
- https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c
- https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47
- https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c
- https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47
Modified: 2025-02-13
CVE-2023-1281
Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when 'tcf_exts_exec()' is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root. This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2.
- http://www.openwall.com/lists/oss-security/2023/04/11/3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230427-0004/
- http://www.openwall.com/lists/oss-security/2023/04/11/3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230427-0004/
Modified: 2025-01-27
CVE-2023-52646
In the Linux kernel, the following vulnerability has been resolved: aio: fix mremap after fork null-deref Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [jmoyer@redhat.com: fix 80 column issue]
- https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1
- https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2
- https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95
- https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1
- https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d
- https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f
- https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22
- https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1
- https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2
- https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95
- https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1
- https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d
- https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f
- https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22
Modified: 2024-12-31
CVE-2023-52702
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached.
- https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536
- https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5
- https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6
- https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e
- https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536
- https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5
- https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6
- https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e
Modified: 2025-09-23
CVE-2023-52703
In the Linux kernel, the following vulnerability has been resolved: net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
- https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc
- https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5
- https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb
- https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030
- https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081
- https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042
- https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a8797016
- https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc
- https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5
- https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb
- https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030
- https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081
- https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042
- https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a8797016
Modified: 2024-12-31
CVE-2023-52705
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes. Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
phys_seg 1 prio class 2
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
of segments to nilfs_sufile_resize(), corrupting parameters such as the
number of segments in superblocks. This causes excessive loop iterations
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
semaphore ns_segctor_sem to block for a long time and hang the writer
thread:
INFO: task segctord:5067 blocked for more than 143 seconds.
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:segctord state:D stack:23456 pid:5067 ppid:2
flags:0x00004000
Call Trace:
- https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5
- https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b
- https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f
- https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d
- https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205
- https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4
- https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff
- https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5
- https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b
- https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f
- https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d
- https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205
- https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4
- https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff
Modified: 2025-01-06
CVE-2023-52707
In the Linux kernel, the following vulnerability has been resolved:
sched/psi: Fix use-after-free in ep_remove_wait_queue()
If a non-root cgroup gets removed when there is a thread that registered
trigger and is polling on a pressure file within the cgroup, the polling
waitqueue gets freed in the following path:
do_rmdir
cgroup_rmdir
kernfs_drain_open_files
cgroup_file_release
cgroup_pressure_release
psi_trigger_destroy
However, the polling thread still has a reference to the pressure file and
will access the freed waitqueue when the file is closed or upon exit:
fput
ep_eventpoll_release
ep_free
ep_remove_wait_queue
remove_wait_queue
This results in use-after-free as pasted below.
The fundamental problem here is that cgroup_file_release() (and
consequently waitqueue's lifetime) is not tied to the file's real lifetime.
Using wake_up_pollfree() here might be less than ideal, but it is in line
with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
since the waitqueue's lifetime is not tied to file's one and can be
considered as another special case. While this would be fixable by somehow
making cgroup_file_release() be tied to the fput(), it would require
sizable refactoring at cgroups or higher layer which might be more
justifiable if we identify more cases like this.
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
Write of size 4 at addr ffff88810e625328 by task a.out/4404
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
Call Trace:
- https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38
- https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe
- https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a
- https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a
- https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5
- https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38
- https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe
- https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a
- https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a
- https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5
Modified: 2025-01-06
CVE-2023-52708
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_spi: fix error handling in mmc_spi_probe() If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host(). To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.
- https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be
- https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f
- https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714
- https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd
- https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3
- https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be
- https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f
- https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714
- https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd
- https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3
Modified: 2025-09-23
CVE-2023-52730
In the Linux kernel, the following vulnerability has been resolved: mmc: sdio: fix possible resource leaks in some error paths If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
- https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd
- https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931
- https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a
- https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280f308ded
- https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e
- https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58
- https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72
- https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd
- https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931
- https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a
- https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280f308ded
- https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e
- https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58
- https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72
Modified: 2025-09-23
CVE-2023-52736
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack.
- https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0
- https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8
- https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a
- https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668
- https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0
- https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8
- https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a
- https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668
Modified: 2026-01-14
CVE-2023-53224
In the Linux kernel, the following vulnerability has been resolved:
ext4: Fix function prototype mismatch for ext4_feat_ktype
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.
ext4_feat_ktype was setting the "release" handler to "kfree", which
doesn't have a matching function prototype. Add a simple wrapper
with the correct prototype.
This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches.
Note that this code is only reached when ext4 is a loadable module and
it is being unloaded:
CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)
...
RIP: 0010:kobject_put+0xbb/0x1b0
...
Call Trace:
- https://git.kernel.org/stable/c/0a1394e07c5d6bf1bfc25db8589ff1b1bfb6f46a
- https://git.kernel.org/stable/c/118901ad1f25d2334255b3d50512fa20591531cd
- https://git.kernel.org/stable/c/1ba10d3640e9783dad811fe4e24d55465c37c64d
- https://git.kernel.org/stable/c/2b69cdd9f9a7f596e3dd31f05f9852940d177924
- https://git.kernel.org/stable/c/94d8de83286fb1827340eba35b61c308f6b46ead
- https://git.kernel.org/stable/c/99e3fd21f8fc975c95e8cf76fbf6a3d2656f8f71
- https://git.kernel.org/stable/c/c98077f7598a562f51051eec043be0cb3e1b1b5e
