ALT-BU-2025-1428-3
Branch p9 update bulletin.
Package kernel-image-un-def updated to version 5.10.233-alt1 for branch p9 in task 368463.
Closed vulnerabilities
Modified: 2025-05-01
BDU:2024-06753
Уязвимость функции ip6_finish_output2 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-01776
Уязвимость функции services_compute_xperms_decision() в модуле security/selinux/ss/services.c системы контроля доступа SELinux ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-29
BDU:2025-01842
Уязвимость функции sctp_association_init() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код.
Modified: 2026-01-20
BDU:2025-02812
Уязвимость функции close_ctree() модуля fs/btrfs/disk-io.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-10-29
BDU:2025-02845
Уязвимость функции ila_add_mapping() модуля net/ipv6/ila/ila_xlat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-10-29
BDU:2025-03060
Уязвимость функции send_io_resp_imm() модуля drivers/infiniband/ulp/rtrs/rtrs-srv.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03510
Уязвимость функций mcp_pinconf_get() и mcp_pinconf_set() драйвера (drivers/pinctrl/pinctrl-mcp23s08.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03512
Уязвимость функции uverbs_request_next_ptr() драйвера (drivers/infiniband/core/uverbs_cmd.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-04146
Уязвимость функции cake_drop() модуля net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04481
Уязвимость функции nr_route_frame() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04487
Уязвимость функции throttle_direct_reclaim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04489
Уязвимость функции nft_set_ext ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04662
Уязвимость функции vlan_get_protocol_dgram() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04699
Уязвимость функции drm_dp_decode_sideband_msg_hdr() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-05094
Уязвимость компонента netdevsim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-06427
Уязвимость функции vlan_get_tci() в модуле net/packet/af_packet.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-06549
Уязвимость компонента virtio-blk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07750
Уязвимость компонента fs/nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07754
Уязвимость компонентов hv_kvp.c, hv_snapshot.c, hv_util.c, hyperv_vmbus.h, hyperv.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07837
Уязвимость компонента megaraid_sas_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07838
Уязвимость компонента drivers/power/supply/gpio-charger.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07839
Уязвимость компонента net/smc/smc_clc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08001
Уязвимость компонента net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12487
Уязвимость ядра операционной системы Linux, связанная с некорректной проверкой количества данных на входе, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-04
CVE-2022-50313
In the Linux kernel, the following vulnerability has been resolved: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com
- https://git.kernel.org/stable/c/0ab621fcdff1a58ff4de51a8590fa92a0ecd34be
- https://git.kernel.org/stable/c/17a0cdbd7b0cf0fc0d7ca4187a67f8f1c18c291f
- https://git.kernel.org/stable/c/1dd73601a1cba37a0ed5f89a8662c90191df5873
- https://git.kernel.org/stable/c/6235fb899b25fd287d5e42635ff82196395708cc
- https://git.kernel.org/stable/c/acc2f40b980c61a9178b72cdedd150b829064997
- https://git.kernel.org/stable/c/b6c8330f5b0f22149957a2e4977fd0f01a9db7cd
Modified: 2025-11-03
CVE-2024-36476
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs: Ensure 'ib_sge list' is accessible Move the declaration of the 'ib_sge list' variable outside the 'always_invalidate' block to ensure it remains accessible for use throughout the function. Previously, 'ib_sge list' was declared within the 'always_invalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10 This change ensures the variable is available for subsequent operations that require it. [1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/
- https://git.kernel.org/stable/c/143378075904e78b3b2a810099bcc3b3d82d762f
- https://git.kernel.org/stable/c/32e1e748a85bd52b20b3857d80fd166d22fa455a
- https://git.kernel.org/stable/c/6ffb5c1885195ae5211a12b4acd2d51843ca41b0
- https://git.kernel.org/stable/c/7eaa71f56a6f7ab87957213472dc6d4055862722
- https://git.kernel.org/stable/c/b238f61cc394d5fef27b26d7d9aa383ebfddabb0
- https://git.kernel.org/stable/c/fb514b31395946022f13a08e06a435f53cf9e8b3
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2026-04-09
CVE-2024-44986
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in ip6_finish_output2() If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed. We need to hold rcu_read_lock() to make sure the dst and associated idev are alive.
- https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e
- https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a
- https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b
- https://git.kernel.org/stable/c/da273b377ae0d9bd255281ed3c2adb228321687b
- https://git.kernel.org/stable/c/e891b36de161fcd96f12ff83667473e5067b9037
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-49571
In the Linux kernel, the following vulnerability has been resolved: net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg When receiving proposal msg in server, the field iparea_offset and the field ipv6_prefixes_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field iparea_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
- https://git.kernel.org/stable/c/47ce46349672a7e0c361bfe39ed0b22e824ef4fb
- https://git.kernel.org/stable/c/62056d1592e63d85e82357ee2ae6a6a294f440b0
- https://git.kernel.org/stable/c/846bada23bfcdeb83621b045ed85dc06c7833ff0
- https://git.kernel.org/stable/c/91a7c27c1444ed4677b83fd5308d2cf03f5f0851
- https://git.kernel.org/stable/c/a29e220d3c8edbf0e1beb0f028878a4a85966556
- https://git.kernel.org/stable/c/f10635268a0a49ee902a3b63b5dbb76f4fed498e
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2025-11-03
CVE-2024-53164
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.
- https://git.kernel.org/stable/c/33db36b3c53d0fda2699ea39ba72bee4de8336e8
- https://git.kernel.org/stable/c/44782565e1e6174c94bddfa72ac7267cd09c1648
- https://git.kernel.org/stable/c/489422e2befff88a1de52b2acebe7b333bded025
- https://git.kernel.org/stable/c/5e473f462a16f1a34e49ea4289a667d2e4f35b52
- https://git.kernel.org/stable/c/5eb7de8cd58e73851cd37ff8d0666517d9926948
- https://git.kernel.org/stable/c/97e13434b5da8e91bdf965352fad2141d13d72d3
- https://git.kernel.org/stable/c/e3e54ad9eff8bdaa70f897e5342e34b76109497f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-53690
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent use of deleted inode
syzbot reported a WARNING in nilfs_rmdir. [1]
Because the inode bitmap is corrupted, an inode with an inode number that
should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0",
causing an inode duplication during execution. And this causes an
underflow of i_nlink in rmdir operations.
The inode is used twice by the same task to unmount and remove directories
".nilfs" and "file0", it trigger warning in nilfs_rmdir.
Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means
that this inode has been deleted, and iput is executed to reclaim it.
[1]
WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407
...
Call Trace:
- https://git.kernel.org/stable/c/284760b320a0bac411b18108316939707dccb12b
- https://git.kernel.org/stable/c/55e4baa0d32f0530ddc64c26620e1f2f8fa2724c
- https://git.kernel.org/stable/c/5d4ed71327b0b5f3b179a19dc3c06be9509ab3db
- https://git.kernel.org/stable/c/901ce9705fbb9f330ff1f19600e5daf9770b0175
- https://git.kernel.org/stable/c/912188316a8c9e41b8c1603c2276a05043b14f96
- https://git.kernel.org/stable/c/ef942d233643777f7b2a5deef620e82942983143
- https://git.kernel.org/stable/c/ff561987ff12b6a3233431ff659b5d332e22f153
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-54031
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_hash: unaligned atomic read on struct nft_set_ext Access to genmask field in struct nft_set_ext results in unaligned atomic read: [ 72.130109] Unable to handle kernel paging request at virtual address ffff0000c2bb708c [ 72.131036] Mem abort info: [ 72.131213] ESR = 0x0000000096000021 [ 72.131446] EC = 0x25: DABT (current EL), IL = 32 bits [ 72.132209] SET = 0, FnV = 0 [ 72.133216] EA = 0, S1PTW = 0 [ 72.134080] FSC = 0x21: alignment fault [ 72.135593] Data abort info: [ 72.137194] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 72.142351] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 72.145989] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 72.150115] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000237d27000 [ 72.154893] [ffff0000c2bb708c] pgd=0000000000000000, p4d=180000023ffff403, pud=180000023f84b403, pmd=180000023f835403, +pte=0068000102bb7707 [ 72.163021] Internal error: Oops: 0000000096000021 [#1] SMP [...] [ 72.170041] CPU: 7 UID: 0 PID: 54 Comm: kworker/7:0 Tainted: G E 6.13.0-rc3+ #2 [ 72.170509] Tainted: [E]=UNSIGNED_MODULE [ 72.170720] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-stable202302-for-qemu 03/01/2023 [ 72.171192] Workqueue: events_power_efficient nft_rhash_gc [nf_tables] [ 72.171552] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 72.171915] pc : nft_rhash_gc+0x200/0x2d8 [nf_tables] [ 72.172166] lr : nft_rhash_gc+0x128/0x2d8 [nf_tables] [ 72.172546] sp : ffff800081f2bce0 [ 72.172724] x29: ffff800081f2bd40 x28: ffff0000c2bb708c x27: 0000000000000038 [ 72.173078] x26: ffff0000c6780ef0 x25: ffff0000c643df00 x24: ffff0000c6778f78 [ 72.173431] x23: 000000000000001a x22: ffff0000c4b1f000 x21: ffff0000c6780f78 [ 72.173782] x20: ffff0000c2bb70dc x19: ffff0000c2bb7080 x18: 0000000000000000 [ 72.174135] x17: ffff0000c0a4e1c0 x16: 0000000000003000 x15: 0000ac26d173b978 [ 72.174485] x14: ffffffffffffffff x13: 0000000000000030 x12: ffff0000c6780ef0 [ 72.174841] x11: 0000000000000000 x10: ffff800081f2bcf8 x9 : ffff0000c3000000 [ 72.175193] x8 : 00000000000004be x7 : 0000000000000000 x6 : 0000000000000000 [ 72.175544] x5 : 0000000000000040 x4 : ffff0000c3000010 x3 : 0000000000000000 [ 72.175871] x2 : 0000000000003a98 x1 : ffff0000c2bb708c x0 : 0000000000000004 [ 72.176207] Call trace: [ 72.176316] nft_rhash_gc+0x200/0x2d8 [nf_tables] (P) [ 72.176653] process_one_work+0x178/0x3d0 [ 72.176831] worker_thread+0x200/0x3f0 [ 72.176995] kthread+0xe8/0xf8 [ 72.177130] ret_from_fork+0x10/0x20 [ 72.177289] Code: 54fff984 d503201f d2800080 91003261 (f820303f) [ 72.177557] ---[ end trace 0000000000000000 ]--- Align struct nft_set_ext to word size to address this and documentation it. pahole reports that this increases the size of elements for rhash and pipapo in 8 bytes on x86_64.
- https://git.kernel.org/stable/c/277f00b0c2dca8794cf4837722960bdc4174911f
- https://git.kernel.org/stable/c/352f8eaaabd008f09d1e176194edc261a7304084
- https://git.kernel.org/stable/c/4f49349c1963e507aa37c1ec05178faeb0103959
- https://git.kernel.org/stable/c/542ed8145e6f9392e3d0a86a0e9027d2ffd183e4
- https://git.kernel.org/stable/c/607774a13764676d4b8be9c8b9c66b8cf3469043
- https://git.kernel.org/stable/c/6a14b46052eeb83175a95baf399283860b9d94c4
- https://git.kernel.org/stable/c/d24cbc43cc7b41a0824b0bc6ec4d8436d8d7a9c0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-55916
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:
hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
vmbus_recvpacket
hv_kvp_onchannelcallback
vmbus_on_event
tasklet_action_common
tasklet_action
handle_softirqs
irq_exit_rcu
sysvec_hyperv_stimer0
- https://git.kernel.org/stable/c/042253c57be901bfd19f15b68267442b70f510d5
- https://git.kernel.org/stable/c/07a756a49f4b4290b49ea46e089cbe6f79ff8d26
- https://git.kernel.org/stable/c/3dd7a30c6d7f90afcf19e9b072f572ba524d7ec6
- https://git.kernel.org/stable/c/718fe694a334be9d1a89eed22602369ac18d6583
- https://git.kernel.org/stable/c/89fcec5e466b3ac9b376e0d621c71effa1a7983f
- https://git.kernel.org/stable/c/d81f4e73aff9b861671df60e5100ad25cc16fbf8
- https://git.kernel.org/stable/c/f091a224a2c82f1e302b1768d73bb6332f687321
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-56616
In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Fix MST sideband message body length check Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message. This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drm_dp_sideband_append_payload() and the following errors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
- https://git.kernel.org/stable/c/109f91d8b9335b0f3714ef9920eae5a8b21d56af
- https://git.kernel.org/stable/c/1fc1f32c4a3421b9d803f18ec3ef49db2fb5d5ef
- https://git.kernel.org/stable/c/70e7166612f4e6da8d7d0305c47c465d88d037e5
- https://git.kernel.org/stable/c/780fa184d4dc38ad6c4fded345ab8f9be7a63e96
- https://git.kernel.org/stable/c/bd2fccac61b40eaf08d9546acc9fef958bfe4763
- https://git.kernel.org/stable/c/c58947a8d4a500902597ee1dbadf0518d7ff8801
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-56716
In the Linux kernel, the following vulnerability has been resolved: netdevsim: prevent bad user input in nsim_dev_health_break_write() If either a zero count or a large one is provided, kernel can crash.
- https://git.kernel.org/stable/c/470c5ecbac2f19b1cdee2a6ce8d5650c3295c94b
- https://git.kernel.org/stable/c/81bdfcd6e6a998e219c9dd49ec7291c2e0594bbc
- https://git.kernel.org/stable/c/8e9ef6bdf71bf25f4735e0230ce1919de8985835
- https://git.kernel.org/stable/c/b3a6daaf7cfb2de37b89fd7a5a2ad4ea9aa3e181
- https://git.kernel.org/stable/c/d10321be26ff9e9e912697e9e8448099654ff561
- https://git.kernel.org/stable/c/ee76746387f6233bdfa93d7406990f923641568f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57791
In the Linux kernel, the following vulnerability has been resolved: net/smc: check return value of sock_recvmsg when draining clc data When receiving clc msg, the field length in smc_clc_msg_hdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smc_clc_wait_msg it may run into deadloop when trying to drain the remaining data exceeding buflen. This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining.
- https://git.kernel.org/stable/c/6b80924af6216277892d5f091f5bfc7d1265fa28
- https://git.kernel.org/stable/c/7a6927814b4256d603e202ae7c5e38db3b338896
- https://git.kernel.org/stable/c/82c7ad9ca09975aae737abffd66d1ad98874c13d
- https://git.kernel.org/stable/c/c5b8ee5022a19464783058dc6042e8eefa34e8cd
- https://git.kernel.org/stable/c/d7d1f986ebb284b1db8dafca7d1bdb6dd2445cf6
- https://git.kernel.org/stable/c/df3dfe1a93c6298d8c09a18e4fba19ef5b17763b
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57792
In the Linux kernel, the following vulnerability has been resolved: power: supply: gpio-charger: Fix set charge current limits Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory.
- https://git.kernel.org/stable/c/13eb3cae1d8e23cce96c095abe34da8028c09ac5
- https://git.kernel.org/stable/c/6abbbd8286b6f944eecf3c74444c138590135211
- https://git.kernel.org/stable/c/afc6e39e824ad0e44b2af50a97885caec8d213d1
- https://git.kernel.org/stable/c/b29c7783ac1fe36d639c089cf471ac7a46df05f0
- https://git.kernel.org/stable/c/c3703d9340ca2820e1ac63256f4b423ea8559831
- https://git.kernel.org/stable/c/f6279a98db132da0cfff18712a1b06478c32007f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57802
In the Linux kernel, the following vulnerability has been resolved: netrom: check buffer length before accessing it Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation. ===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nr_route_frame does not validate the buffer size before using it. Fix this issue by checking skb->len before accessing any fields in skb->data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/3ba7f80d98d4965349cfcd258dd78418496c1625
- https://git.kernel.org/stable/c/64e9f54a14f2887be8634fb85cd2f13bec18a184
- https://git.kernel.org/stable/c/769e36c2119a51070faf58819c58274f57a088db
- https://git.kernel.org/stable/c/78a110332ae268d0b005247c3b9a7d703b875c49
- https://git.kernel.org/stable/c/a4fd163aed2edd967a244499754dec991d8b4c7d
- https://git.kernel.org/stable/c/cf6befa7c569787f53440274bbed1405fc07738d
- https://git.kernel.org/stable/c/f647d72245aadce30618f4c8fd3803904418dbec
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57807
In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex.
- https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554
- https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8
- https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7
- https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b
- https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d
- https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815
- https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57884
In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() The task sometimes continues looping in throttle_direct_reclaim() because allow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4 At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of inactive/active file-backed pages calculated in zone_reclaimable_pages() based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 } As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark. The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0 This is because the node deemed balanced. The node balancing logic in balance_pgdat() evaluates all zones collectively. If one or more zones (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balance_pgdat() to exit early before incrementing the kswapd_failures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure. The patch ensures that zone_reclaimable_pages() includes free pages (NR_FREE_PAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONE_DMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONE_NORMAL, and prevents infinite loops in throttle_direct_reclaim() caused by allow_direct_reclaim(pgdat) repeatedly returning false. The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONE_NORMAL. This issue arises from zone_reclaimable_pages ---truncated---
- https://git.kernel.org/stable/c/1ff2302e8aeac7f2eedb551d7a89617283b5c6b2
- https://git.kernel.org/stable/c/58d0d02dbc67438fc80223fdd7bbc49cf0733284
- https://git.kernel.org/stable/c/63eac98d6f0898229f515cb62fe4e4db2430e99c
- https://git.kernel.org/stable/c/66cd37660ec34ec444fe42f2277330ae4a36bb19
- https://git.kernel.org/stable/c/6aaced5abd32e2a57cd94fd64f824514d0361da8
- https://git.kernel.org/stable/c/bfb701192129803191c9cd6cdd1f82cd07f8de2c
- https://git.kernel.org/stable/c/d675fefbaec3815b3ae0af1bebd97f27df3a05c8
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57889
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ... We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C). The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fast_io, .disable_locking, etc. mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex. However, __setup_irq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock. It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcp_pinconf_get/set. mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock(). The accesses to the regmap from mcp23s08_probe_one() do not need additional locking. In all remaining places where the regmap is accessed, except mcp_pinconf_get/set(), the driver already takes mcp->lock. This patch adds locking in mcp_pinconf_get/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above.
- https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb
- https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318
- https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61
- https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec
- https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785
- https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693
- https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57890
In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Prevent integer overflow issue In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems. This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications.
- https://git.kernel.org/stable/c/346db03e9926ab7117ed9bf19665699c037c773c
- https://git.kernel.org/stable/c/42a6eb4ed7a9a41ba0b83eb0c7e0225b5fca5608
- https://git.kernel.org/stable/c/b3ef4ae713360501182695dd47d6b4f6e1a43eb8
- https://git.kernel.org/stable/c/b92667f755749cf10d9ef1088865c555ae83ffb7
- https://git.kernel.org/stable/c/c2f961c46ea0e5274c5c320d007c2dd949cf627a
- https://git.kernel.org/stable/c/c57721b24bd897338a81a0ca5fff41600f0f1ad1
- https://git.kernel.org/stable/c/d0257e089d1bbd35c69b6c97ff73e3690ab149a9
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57896
In the Linux kernel, the following vulnerability has been resolved:
btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount
During the unmount path, at close_ctree(), we first stop the cleaner
kthread, using kthread_stop() which frees the associated task_struct, and
then stop and destroy all the work queues. However after we stopped the
cleaner we may still have a worker from the delalloc_workers queue running
inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),
which in turn tries to wake up the cleaner kthread - which was already
destroyed before, resulting in a use-after-free on the task_struct.
Syzbot reported this with the following stack traces:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089
Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52
CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: btrfs-delalloc btrfs_work_helper
Call Trace:
- https://git.kernel.org/stable/c/1ea629e7bb2fb40555e5e01a1b5095df31287017
- https://git.kernel.org/stable/c/35916b2f96505a18dc7242a115611b718d9de725
- https://git.kernel.org/stable/c/63f4b594a688bf922e8691f0784679aa7af7988c
- https://git.kernel.org/stable/c/a2718ed1eb8c3611b63f8933c7e68c8821fe2808
- https://git.kernel.org/stable/c/d77a3a99b53d12c061c007cdc96df38825dee476
- https://git.kernel.org/stable/c/f10bef73fb355e3fc85e63a50386798be68ff486
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57900
In the Linux kernel, the following vulnerability has been resolved:
ila: serialize calls to nf_register_net_hooks()
syzbot found a race in ila_add_mapping() [1]
commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")
attempted to fix a similar issue.
Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.
Add a mutex to make sure at most one thread is calling nf_register_net_hooks().
[1]
BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501
CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
- https://git.kernel.org/stable/c/1638f430f8900f2375f5de45508fbe553997e190
- https://git.kernel.org/stable/c/17e8fa894345e8d2c7a7642482267b275c3d4553
- https://git.kernel.org/stable/c/260466b576bca0081a7d4acecc8e93687aa22d0e
- https://git.kernel.org/stable/c/3d1b63cf468e446b9feaf4e4e73182b9cc82f460
- https://git.kernel.org/stable/c/ad0677c37c14fa28913daea92d139644d7acf04e
- https://git.kernel.org/stable/c/d3017895e393536b234cf80a83fc463c08a28137
- https://git.kernel.org/stable/c/eba25e21dce7ec70e2b3f121b2f3a25a4ec43eca
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57901
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
by syzbot.
Rework vlan_get_protocol_dgram() to not touch skb at all,
so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1]
skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:
- https://git.kernel.org/stable/c/0d3fa6c3c9ca7aa255696150f5b759ac4a4974e1
- https://git.kernel.org/stable/c/560cbdd26b510626f3f4f27d34c44dfd3dd3499d
- https://git.kernel.org/stable/c/5d336714db324bef84490c75dcc48b387ef0346e
- https://git.kernel.org/stable/c/a693b87692b4d7c50f4fc08a996678d60534a9da
- https://git.kernel.org/stable/c/cd8488fdc7116f6da277515647b167859d4f72b1
- https://git.kernel.org/stable/c/de4f8d477c67ec1d7c28f3486c3e47d147d90a01
- https://git.kernel.org/stable/c/f91a5b8089389eb408501af2762f168c3aaa7b79
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57902
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_tci() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
by syzbot.
Rework vlan_get_tci() to not touch skb at all,
so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1]
skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:
- https://git.kernel.org/stable/c/65c67049e9ed481f6b52264b39618b8c6dfb1d3e
- https://git.kernel.org/stable/c/66ffb0cf2125dcf9e902eede4a43653a24fd9cb2
- https://git.kernel.org/stable/c/77ee7a6d16b6ec07b5c3ae2b6b60a24c1afbed09
- https://git.kernel.org/stable/c/7aa78d0d8546d8ce5a764add3f55d72e707c18f1
- https://git.kernel.org/stable/c/b65292a548d847099a4fe0fff53122a06e798e25
- https://git.kernel.org/stable/c/d91b4a9baa018a001d5c884e236c0cfd31f9f4a1
- https://git.kernel.org/stable/c/fa57f07ba0622c8692f40e1300adca59277b0044
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57931
In the Linux kernel, the following vulnerability has been resolved: selinux: ignore unknown extended permissions When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels.
- https://git.kernel.org/stable/c/712137b177b45f255ce5687e679d950fcb218256
- https://git.kernel.org/stable/c/900f83cf376bdaf798b6f5dcb2eae0c822e908b6
- https://git.kernel.org/stable/c/c1dbd28a079553de0023e1c938c713efeeee400f
- https://git.kernel.org/stable/c/c79324d42fa48372e0acb306a2761cc642bd4db0
- https://git.kernel.org/stable/c/efefe36c03a73bb81c0720ce397659a5051b73fa
- https://git.kernel.org/stable/c/f45a77dd24ae9ddb474303ec3975c376bd99fc51
- https://git.kernel.org/stable/c/f70e4b9ec69d9a74b84c17767a9a4eda8c901021
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57938
In the Linux kernel, the following vulnerability has been resolved: net/sctp: Prevent autoclose integer overflow in sctp_association_init() While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow.
- https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53
- https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94
- https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477
- https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d
- https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a
- https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e
- https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57946
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: don't keep queue frozen during system suspend Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.
- https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea
- https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4
- https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37
- https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516
- https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2
- https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4
- https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Package kernel-image-std-def updated to version 5.4.289-alt1 for branch p9 in task 368470.
Closed vulnerabilities
Modified: 2025-05-01
BDU:2024-06753
Уязвимость функции ip6_finish_output2 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-01776
Уязвимость функции services_compute_xperms_decision() в модуле security/selinux/ss/services.c системы контроля доступа SELinux ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-29
BDU:2025-01842
Уязвимость функции sctp_association_init() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код.
Modified: 2025-10-29
BDU:2025-02845
Уязвимость функции ila_add_mapping() модуля net/ipv6/ila/ila_xlat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-10-29
BDU:2025-03510
Уязвимость функций mcp_pinconf_get() и mcp_pinconf_set() драйвера (drivers/pinctrl/pinctrl-mcp23s08.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03512
Уязвимость функции uverbs_request_next_ptr() драйвера (drivers/infiniband/core/uverbs_cmd.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-04146
Уязвимость функции cake_drop() модуля net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04481
Уязвимость функции nr_route_frame() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04487
Уязвимость функции throttle_direct_reclaim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-04489
Уязвимость функции nft_set_ext ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-04662
Уязвимость функции vlan_get_protocol_dgram() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-06427
Уязвимость функции vlan_get_tci() в модуле net/packet/af_packet.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-06549
Уязвимость компонента virtio-blk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07750
Уязвимость компонента fs/nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07754
Уязвимость компонентов hv_kvp.c, hv_snapshot.c, hv_util.c, hyperv_vmbus.h, hyperv.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-07837
Уязвимость компонента megaraid_sas_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12487
Уязвимость ядра операционной системы Linux, связанная с некорректной проверкой количества данных на входе, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-04
CVE-2022-50313
In the Linux kernel, the following vulnerability has been resolved: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com
- https://git.kernel.org/stable/c/0ab621fcdff1a58ff4de51a8590fa92a0ecd34be
- https://git.kernel.org/stable/c/17a0cdbd7b0cf0fc0d7ca4187a67f8f1c18c291f
- https://git.kernel.org/stable/c/1dd73601a1cba37a0ed5f89a8662c90191df5873
- https://git.kernel.org/stable/c/6235fb899b25fd287d5e42635ff82196395708cc
- https://git.kernel.org/stable/c/acc2f40b980c61a9178b72cdedd150b829064997
- https://git.kernel.org/stable/c/b6c8330f5b0f22149957a2e4977fd0f01a9db7cd
Modified: 2026-04-09
CVE-2024-44986
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in ip6_finish_output2() If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed. We need to hold rcu_read_lock() to make sure the dst and associated idev are alive.
- https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e
- https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a
- https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b
- https://git.kernel.org/stable/c/da273b377ae0d9bd255281ed3c2adb228321687b
- https://git.kernel.org/stable/c/e891b36de161fcd96f12ff83667473e5067b9037
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-53164
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.
- https://git.kernel.org/stable/c/33db36b3c53d0fda2699ea39ba72bee4de8336e8
- https://git.kernel.org/stable/c/44782565e1e6174c94bddfa72ac7267cd09c1648
- https://git.kernel.org/stable/c/489422e2befff88a1de52b2acebe7b333bded025
- https://git.kernel.org/stable/c/5e473f462a16f1a34e49ea4289a667d2e4f35b52
- https://git.kernel.org/stable/c/5eb7de8cd58e73851cd37ff8d0666517d9926948
- https://git.kernel.org/stable/c/97e13434b5da8e91bdf965352fad2141d13d72d3
- https://git.kernel.org/stable/c/e3e54ad9eff8bdaa70f897e5342e34b76109497f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-53690
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent use of deleted inode
syzbot reported a WARNING in nilfs_rmdir. [1]
Because the inode bitmap is corrupted, an inode with an inode number that
should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0",
causing an inode duplication during execution. And this causes an
underflow of i_nlink in rmdir operations.
The inode is used twice by the same task to unmount and remove directories
".nilfs" and "file0", it trigger warning in nilfs_rmdir.
Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means
that this inode has been deleted, and iput is executed to reclaim it.
[1]
WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407
...
Call Trace:
- https://git.kernel.org/stable/c/284760b320a0bac411b18108316939707dccb12b
- https://git.kernel.org/stable/c/55e4baa0d32f0530ddc64c26620e1f2f8fa2724c
- https://git.kernel.org/stable/c/5d4ed71327b0b5f3b179a19dc3c06be9509ab3db
- https://git.kernel.org/stable/c/901ce9705fbb9f330ff1f19600e5daf9770b0175
- https://git.kernel.org/stable/c/912188316a8c9e41b8c1603c2276a05043b14f96
- https://git.kernel.org/stable/c/ef942d233643777f7b2a5deef620e82942983143
- https://git.kernel.org/stable/c/ff561987ff12b6a3233431ff659b5d332e22f153
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-54031
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_hash: unaligned atomic read on struct nft_set_ext Access to genmask field in struct nft_set_ext results in unaligned atomic read: [ 72.130109] Unable to handle kernel paging request at virtual address ffff0000c2bb708c [ 72.131036] Mem abort info: [ 72.131213] ESR = 0x0000000096000021 [ 72.131446] EC = 0x25: DABT (current EL), IL = 32 bits [ 72.132209] SET = 0, FnV = 0 [ 72.133216] EA = 0, S1PTW = 0 [ 72.134080] FSC = 0x21: alignment fault [ 72.135593] Data abort info: [ 72.137194] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 72.142351] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 72.145989] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 72.150115] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000237d27000 [ 72.154893] [ffff0000c2bb708c] pgd=0000000000000000, p4d=180000023ffff403, pud=180000023f84b403, pmd=180000023f835403, +pte=0068000102bb7707 [ 72.163021] Internal error: Oops: 0000000096000021 [#1] SMP [...] [ 72.170041] CPU: 7 UID: 0 PID: 54 Comm: kworker/7:0 Tainted: G E 6.13.0-rc3+ #2 [ 72.170509] Tainted: [E]=UNSIGNED_MODULE [ 72.170720] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-stable202302-for-qemu 03/01/2023 [ 72.171192] Workqueue: events_power_efficient nft_rhash_gc [nf_tables] [ 72.171552] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 72.171915] pc : nft_rhash_gc+0x200/0x2d8 [nf_tables] [ 72.172166] lr : nft_rhash_gc+0x128/0x2d8 [nf_tables] [ 72.172546] sp : ffff800081f2bce0 [ 72.172724] x29: ffff800081f2bd40 x28: ffff0000c2bb708c x27: 0000000000000038 [ 72.173078] x26: ffff0000c6780ef0 x25: ffff0000c643df00 x24: ffff0000c6778f78 [ 72.173431] x23: 000000000000001a x22: ffff0000c4b1f000 x21: ffff0000c6780f78 [ 72.173782] x20: ffff0000c2bb70dc x19: ffff0000c2bb7080 x18: 0000000000000000 [ 72.174135] x17: ffff0000c0a4e1c0 x16: 0000000000003000 x15: 0000ac26d173b978 [ 72.174485] x14: ffffffffffffffff x13: 0000000000000030 x12: ffff0000c6780ef0 [ 72.174841] x11: 0000000000000000 x10: ffff800081f2bcf8 x9 : ffff0000c3000000 [ 72.175193] x8 : 00000000000004be x7 : 0000000000000000 x6 : 0000000000000000 [ 72.175544] x5 : 0000000000000040 x4 : ffff0000c3000010 x3 : 0000000000000000 [ 72.175871] x2 : 0000000000003a98 x1 : ffff0000c2bb708c x0 : 0000000000000004 [ 72.176207] Call trace: [ 72.176316] nft_rhash_gc+0x200/0x2d8 [nf_tables] (P) [ 72.176653] process_one_work+0x178/0x3d0 [ 72.176831] worker_thread+0x200/0x3f0 [ 72.176995] kthread+0xe8/0xf8 [ 72.177130] ret_from_fork+0x10/0x20 [ 72.177289] Code: 54fff984 d503201f d2800080 91003261 (f820303f) [ 72.177557] ---[ end trace 0000000000000000 ]--- Align struct nft_set_ext to word size to address this and documentation it. pahole reports that this increases the size of elements for rhash and pipapo in 8 bytes on x86_64.
- https://git.kernel.org/stable/c/277f00b0c2dca8794cf4837722960bdc4174911f
- https://git.kernel.org/stable/c/352f8eaaabd008f09d1e176194edc261a7304084
- https://git.kernel.org/stable/c/4f49349c1963e507aa37c1ec05178faeb0103959
- https://git.kernel.org/stable/c/542ed8145e6f9392e3d0a86a0e9027d2ffd183e4
- https://git.kernel.org/stable/c/607774a13764676d4b8be9c8b9c66b8cf3469043
- https://git.kernel.org/stable/c/6a14b46052eeb83175a95baf399283860b9d94c4
- https://git.kernel.org/stable/c/d24cbc43cc7b41a0824b0bc6ec4d8436d8d7a9c0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-55916
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:
hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
vmbus_recvpacket
hv_kvp_onchannelcallback
vmbus_on_event
tasklet_action_common
tasklet_action
handle_softirqs
irq_exit_rcu
sysvec_hyperv_stimer0
- https://git.kernel.org/stable/c/042253c57be901bfd19f15b68267442b70f510d5
- https://git.kernel.org/stable/c/07a756a49f4b4290b49ea46e089cbe6f79ff8d26
- https://git.kernel.org/stable/c/3dd7a30c6d7f90afcf19e9b072f572ba524d7ec6
- https://git.kernel.org/stable/c/718fe694a334be9d1a89eed22602369ac18d6583
- https://git.kernel.org/stable/c/89fcec5e466b3ac9b376e0d621c71effa1a7983f
- https://git.kernel.org/stable/c/d81f4e73aff9b861671df60e5100ad25cc16fbf8
- https://git.kernel.org/stable/c/f091a224a2c82f1e302b1768d73bb6332f687321
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57802
In the Linux kernel, the following vulnerability has been resolved: netrom: check buffer length before accessing it Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation. ===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nr_route_frame does not validate the buffer size before using it. Fix this issue by checking skb->len before accessing any fields in skb->data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/3ba7f80d98d4965349cfcd258dd78418496c1625
- https://git.kernel.org/stable/c/64e9f54a14f2887be8634fb85cd2f13bec18a184
- https://git.kernel.org/stable/c/769e36c2119a51070faf58819c58274f57a088db
- https://git.kernel.org/stable/c/78a110332ae268d0b005247c3b9a7d703b875c49
- https://git.kernel.org/stable/c/a4fd163aed2edd967a244499754dec991d8b4c7d
- https://git.kernel.org/stable/c/cf6befa7c569787f53440274bbed1405fc07738d
- https://git.kernel.org/stable/c/f647d72245aadce30618f4c8fd3803904418dbec
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57807
In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex.
- https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554
- https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8
- https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7
- https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b
- https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d
- https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815
- https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57884
In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() The task sometimes continues looping in throttle_direct_reclaim() because allow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4 At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of inactive/active file-backed pages calculated in zone_reclaimable_pages() based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 } As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark. The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0 This is because the node deemed balanced. The node balancing logic in balance_pgdat() evaluates all zones collectively. If one or more zones (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balance_pgdat() to exit early before incrementing the kswapd_failures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure. The patch ensures that zone_reclaimable_pages() includes free pages (NR_FREE_PAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONE_DMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONE_NORMAL, and prevents infinite loops in throttle_direct_reclaim() caused by allow_direct_reclaim(pgdat) repeatedly returning false. The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONE_NORMAL. This issue arises from zone_reclaimable_pages ---truncated---
- https://git.kernel.org/stable/c/1ff2302e8aeac7f2eedb551d7a89617283b5c6b2
- https://git.kernel.org/stable/c/58d0d02dbc67438fc80223fdd7bbc49cf0733284
- https://git.kernel.org/stable/c/63eac98d6f0898229f515cb62fe4e4db2430e99c
- https://git.kernel.org/stable/c/66cd37660ec34ec444fe42f2277330ae4a36bb19
- https://git.kernel.org/stable/c/6aaced5abd32e2a57cd94fd64f824514d0361da8
- https://git.kernel.org/stable/c/bfb701192129803191c9cd6cdd1f82cd07f8de2c
- https://git.kernel.org/stable/c/d675fefbaec3815b3ae0af1bebd97f27df3a05c8
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57889
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ... We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C). The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fast_io, .disable_locking, etc. mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex. However, __setup_irq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock. It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcp_pinconf_get/set. mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock(). The accesses to the regmap from mcp23s08_probe_one() do not need additional locking. In all remaining places where the regmap is accessed, except mcp_pinconf_get/set(), the driver already takes mcp->lock. This patch adds locking in mcp_pinconf_get/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above.
- https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb
- https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318
- https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61
- https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec
- https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785
- https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693
- https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57890
In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Prevent integer overflow issue In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems. This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications.
- https://git.kernel.org/stable/c/346db03e9926ab7117ed9bf19665699c037c773c
- https://git.kernel.org/stable/c/42a6eb4ed7a9a41ba0b83eb0c7e0225b5fca5608
- https://git.kernel.org/stable/c/b3ef4ae713360501182695dd47d6b4f6e1a43eb8
- https://git.kernel.org/stable/c/b92667f755749cf10d9ef1088865c555ae83ffb7
- https://git.kernel.org/stable/c/c2f961c46ea0e5274c5c320d007c2dd949cf627a
- https://git.kernel.org/stable/c/c57721b24bd897338a81a0ca5fff41600f0f1ad1
- https://git.kernel.org/stable/c/d0257e089d1bbd35c69b6c97ff73e3690ab149a9
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57900
In the Linux kernel, the following vulnerability has been resolved:
ila: serialize calls to nf_register_net_hooks()
syzbot found a race in ila_add_mapping() [1]
commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")
attempted to fix a similar issue.
Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.
Add a mutex to make sure at most one thread is calling nf_register_net_hooks().
[1]
BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501
CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
- https://git.kernel.org/stable/c/1638f430f8900f2375f5de45508fbe553997e190
- https://git.kernel.org/stable/c/17e8fa894345e8d2c7a7642482267b275c3d4553
- https://git.kernel.org/stable/c/260466b576bca0081a7d4acecc8e93687aa22d0e
- https://git.kernel.org/stable/c/3d1b63cf468e446b9feaf4e4e73182b9cc82f460
- https://git.kernel.org/stable/c/ad0677c37c14fa28913daea92d139644d7acf04e
- https://git.kernel.org/stable/c/d3017895e393536b234cf80a83fc463c08a28137
- https://git.kernel.org/stable/c/eba25e21dce7ec70e2b3f121b2f3a25a4ec43eca
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57901
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
by syzbot.
Rework vlan_get_protocol_dgram() to not touch skb at all,
so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1]
skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:
- https://git.kernel.org/stable/c/0d3fa6c3c9ca7aa255696150f5b759ac4a4974e1
- https://git.kernel.org/stable/c/560cbdd26b510626f3f4f27d34c44dfd3dd3499d
- https://git.kernel.org/stable/c/5d336714db324bef84490c75dcc48b387ef0346e
- https://git.kernel.org/stable/c/a693b87692b4d7c50f4fc08a996678d60534a9da
- https://git.kernel.org/stable/c/cd8488fdc7116f6da277515647b167859d4f72b1
- https://git.kernel.org/stable/c/de4f8d477c67ec1d7c28f3486c3e47d147d90a01
- https://git.kernel.org/stable/c/f91a5b8089389eb408501af2762f168c3aaa7b79
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57902
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_tci() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
by syzbot.
Rework vlan_get_tci() to not touch skb at all,
so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1]
skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:
- https://git.kernel.org/stable/c/65c67049e9ed481f6b52264b39618b8c6dfb1d3e
- https://git.kernel.org/stable/c/66ffb0cf2125dcf9e902eede4a43653a24fd9cb2
- https://git.kernel.org/stable/c/77ee7a6d16b6ec07b5c3ae2b6b60a24c1afbed09
- https://git.kernel.org/stable/c/7aa78d0d8546d8ce5a764add3f55d72e707c18f1
- https://git.kernel.org/stable/c/b65292a548d847099a4fe0fff53122a06e798e25
- https://git.kernel.org/stable/c/d91b4a9baa018a001d5c884e236c0cfd31f9f4a1
- https://git.kernel.org/stable/c/fa57f07ba0622c8692f40e1300adca59277b0044
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57931
In the Linux kernel, the following vulnerability has been resolved: selinux: ignore unknown extended permissions When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels.
- https://git.kernel.org/stable/c/712137b177b45f255ce5687e679d950fcb218256
- https://git.kernel.org/stable/c/900f83cf376bdaf798b6f5dcb2eae0c822e908b6
- https://git.kernel.org/stable/c/c1dbd28a079553de0023e1c938c713efeeee400f
- https://git.kernel.org/stable/c/c79324d42fa48372e0acb306a2761cc642bd4db0
- https://git.kernel.org/stable/c/efefe36c03a73bb81c0720ce397659a5051b73fa
- https://git.kernel.org/stable/c/f45a77dd24ae9ddb474303ec3975c376bd99fc51
- https://git.kernel.org/stable/c/f70e4b9ec69d9a74b84c17767a9a4eda8c901021
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57938
In the Linux kernel, the following vulnerability has been resolved: net/sctp: Prevent autoclose integer overflow in sctp_association_init() While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow.
- https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53
- https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94
- https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477
- https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d
- https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a
- https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e
- https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-57946
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: don't keep queue frozen during system suspend Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.
- https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea
- https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4
- https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37
- https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516
- https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2
- https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4
- https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
