ALT-PU-2025-6382-2
Package kernel-image-std-def updated to version 5.10.237-alt1 for branch p10 in task 383024.
Closed vulnerabilities
BDU:2025-04647
Уязвимость функции resource_build_scaling_params() модуля drivers/gpu/drm/amd/display/dc/core/dc_resource.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-10
CVE-2025-21941
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params Null pointer dereference issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not null before accessing. This prevents a null pointer dereference. Found by code review. (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
- https://git.kernel.org/stable/c/265422915416468ba91bffa56addbff45e18342a
- https://git.kernel.org/stable/c/3748fad09d89e9a5290e1738fd6872a79f794743
- https://git.kernel.org/stable/c/374c9faac5a763a05bc3f68ad9f73dab3c6aec90
- https://git.kernel.org/stable/c/3b3c2be58d5275aa59d8b4810a59f173f2f5bac1
- https://git.kernel.org/stable/c/c1e54752dc12e90305eb0475ca908f42f5b369ca
- https://git.kernel.org/stable/c/e0345c3478f185ca840daac7f08a1fcd4ebec3e9
- https://git.kernel.org/stable/c/f435192e00bc4d5d4134356b93212670ec47fa8d
Modified: 2025-04-11
CVE-2025-21957
In the Linux kernel, the following vulnerability has been resolved: scsi: qla1280: Fix kernel oops when debug level > 2 A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I think its clear from the code that the intention here is sg_dma_len(s) not length of sg_next(s) when printing the debug info.
- https://git.kernel.org/stable/c/11a8dac1177a596648a020a7f3708257a2f95fee
- https://git.kernel.org/stable/c/24602e2664c515a4f2950d7b52c3d5997463418c
- https://git.kernel.org/stable/c/5233e3235dec3065ccc632729675575dbe3c6b8a
- https://git.kernel.org/stable/c/7ac2473e727d67a38266b2b7e55c752402ab588c
- https://git.kernel.org/stable/c/af71ba921d08c241a817010f96458dc5e5e26762
- https://git.kernel.org/stable/c/afa27b7c17a48e01546ccaad0ab017ad0496a522
- https://git.kernel.org/stable/c/c737e2a5fb7f90b96a96121da1b50a9c74ae9b8c
- https://git.kernel.org/stable/c/ea371d1cdefb0951c7127a33bcd7eb931cf44571
Modified: 2025-04-14
CVE-2025-21959
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree() Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbage collection confirm race"), `cpu` and `jiffies32` were introduced to the struct nf_conncount_tuple. The commit made nf_conncount_add() initialize `conn->cpu` and `conn->jiffies32` when allocating the struct. In contrast, count_tree() was not changed to initialize them. By commit 34848d5c896e ("netfilter: nf_conncount: Split insert and traversal"), count_tree() was split and the relevant allocation code now resides in insert_tree(). Initialize `conn->cpu` and `conn->jiffies32` in insert_tree(). BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline] BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip ---truncated---
- https://git.kernel.org/stable/c/2a154ce766b995494e88d8d117fa82cc6b73dd87
- https://git.kernel.org/stable/c/2db5baaf047a7c8d6ed5e2cc657b7854e155b7fc
- https://git.kernel.org/stable/c/a62a25c6ad58fae997f48a0749afeda1c252ae51
- https://git.kernel.org/stable/c/d653bfeb07ebb3499c403404c21ac58a16531607
- https://git.kernel.org/stable/c/db1e0c0856821c59a32ea3af79476bf20a6beeb2
- https://git.kernel.org/stable/c/e8544a5a97bee3674e7cd6bf0f3a4af517fa9146
- https://git.kernel.org/stable/c/f522229c5563b59b4240261e406779bba6754159
- https://git.kernel.org/stable/c/fda50302a13701d47fbe01e1739c7a51114144fb
Modified: 2025-04-14
CVE-2025-21968
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free on hdcp_work [Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running. [How] Cancel the delayed work when destroying workqueue. (cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
- https://git.kernel.org/stable/c/06acfdef370ae018dad9592369e2d2fd9a40c09e
- https://git.kernel.org/stable/c/1397715b011bcdc6ad91b17df7acaee301e89db5
- https://git.kernel.org/stable/c/378b361e2e30e9729f9a7676f7926868d14f4326
- https://git.kernel.org/stable/c/4964dbc4191ab436877a5e3ecd9c67a4e50b7c36
- https://git.kernel.org/stable/c/93d701064e56788663d7c5918fbe5e060d5df587
- https://git.kernel.org/stable/c/bac7b8b1a3f1a86eeec85835af106cbdc2b9d9f7
- https://git.kernel.org/stable/c/e65e7bea220c3ce8c4c793b4ba35557f4994ab2b
Modified: 2025-04-14
CVE-2025-21996
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse() On the off chance that command stream passed from userspace via ioctl() call to radeon_vce_cs_parse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeon_vce_cs_reloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value. Play it safe and init 'tmp' with 0, thus ensuring that radeon_vce_cs_reloc() will catch an early error in cases like these. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. (cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)
- https://git.kernel.org/stable/c/0effb378ebce52b897f85cd7f828854b8c7cb636
- https://git.kernel.org/stable/c/3ce08215cad55c10a6eeeb33d3583b6cfffe3ab8
- https://git.kernel.org/stable/c/5b4d9d20fd455a97920cf158dd19163b879cf65d
- https://git.kernel.org/stable/c/78b07dada3f02f77762d0755a96d35f53b02be69
- https://git.kernel.org/stable/c/9b2da9c673a0da1359a2151f7ce773e2f77d71a9
- https://git.kernel.org/stable/c/dd1801aa01bba1760357f2a641346ae149686713
- https://git.kernel.org/stable/c/dd8689b52a24807c2d5ce0a17cb26dc87f75235c
- https://git.kernel.org/stable/c/f5e049028124f755283f2c07e7a3708361ed1dc8
Modified: 2025-04-10
CVE-2025-22005
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.
- https://git.kernel.org/stable/c/119dcafe36795a15ae53351cbbd6177aaf94ffef
- https://git.kernel.org/stable/c/16267a5036173d0173377545b4b6021b081d0933
- https://git.kernel.org/stable/c/1bd12dfc058e1e68759d313d7727d68dbc1b8964
- https://git.kernel.org/stable/c/29d91820184d5cbc70f3246d4911d96eaeb930d6
- https://git.kernel.org/stable/c/596a883c4ce2d2e9c175f25b98fed3a1f33fea38
- https://git.kernel.org/stable/c/77c41cdbe6bce476e08d3251c0d501feaf10a9f3
- https://git.kernel.org/stable/c/9740890ee20e01f99ff1dde84c63dcf089fabb98
- https://git.kernel.org/stable/c/d3d5b4b5ae263c3225db363ba08b937e2e2b0380
Modified: 2025-05-06
CVE-2025-22018
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725]
- https://git.kernel.org/stable/c/09691f367df44fe93255274d80a439f9bb3263fc
- https://git.kernel.org/stable/c/0ef6e49881b6b50ac454cb9d6501d009fdceb6fc
- https://git.kernel.org/stable/c/14c7aca5ba2740973de27c1bb8df77b4dcb6f775
- https://git.kernel.org/stable/c/1505f9b720656b17865e4166ab002960162bf679
- https://git.kernel.org/stable/c/3c23bb2c894e9ef2727682f98c341b20f78c9013
- https://git.kernel.org/stable/c/9da6b6340dbcf0f60ae3ec6a7d6438337c32518a
- https://git.kernel.org/stable/c/ab92f51c7f53a08f1a686bfb80690ebb3672357d
- https://git.kernel.org/stable/c/bf2986fcf82a449441f9ee4335df19be19e83970
- https://git.kernel.org/stable/c/d7f1e4a53a51cc6ba833afcb40439f18dab61c1f
Modified: 2025-05-06
CVE-2025-22020
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
Call Trace:
- https://git.kernel.org/stable/c/0067cb7d7e7c277e91a0887a3c24e71462379469
- https://git.kernel.org/stable/c/31f0eaed6914333f42501fc7e0f6830879f5ef2d
- https://git.kernel.org/stable/c/4676741a3464b300b486e70585c3c9b692be1632
- https://git.kernel.org/stable/c/52d942a5302eefb3b7a3bfee310a5a33feeedc21
- https://git.kernel.org/stable/c/6186fb2cd36317277a8423687982140a7f3f7841
- https://git.kernel.org/stable/c/75123adf204f997e11bbddee48408c284f51c050
- https://git.kernel.org/stable/c/914c5e5bfceb9878f3056eaf4d1c88f2cbe0a185
- https://git.kernel.org/stable/c/9dfaf4d723c62bda8d9d1340e2e78acf0c190439
- https://git.kernel.org/stable/c/b094e8e3988e02e8cef7a756c8d2cea9c12509ab
Modified: 2025-04-25
CVE-2025-22035
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free in print_graph_function_flags during tracer switching Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
- https://git.kernel.org/stable/c/099ef3385800828b74933a96c117574637c3fb3a
- https://git.kernel.org/stable/c/42561fe62c3628ea3bc9623f64f047605e98857f
- https://git.kernel.org/stable/c/70be951bc01e4a0e10d443f3510bb17426f257fb
- https://git.kernel.org/stable/c/7f81f27b1093e4895e87b74143c59c055c3b1906
- https://git.kernel.org/stable/c/81a85b12132c8ffe98f5ddbdc185481790aeaa1b
- https://git.kernel.org/stable/c/a2cce54c1748216535dda02e185d07a084be837e
- https://git.kernel.org/stable/c/c85efe6e13743cac6ba4ccf144cb91f44c86231a
- https://git.kernel.org/stable/c/de7b309139f862a44379ecd96e93c9133c69f813
- https://git.kernel.org/stable/c/f14752d66056d0c7bffe5092130409417d3baa70
Modified: 2025-04-29
CVE-2025-22054
In the Linux kernel, the following vulnerability has been resolved: arcnet: Add NULL check in com20020pci_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated.
- https://git.kernel.org/stable/c/661cf5d102949898c931e81fd4e1c773afcdeafa
- https://git.kernel.org/stable/c/887226163504494ea7e58033a97c2d2ab12e05d4
- https://git.kernel.org/stable/c/905a34dc1ad9a53a8aaaf8a759ea5dbaaa30418d
- https://git.kernel.org/stable/c/a654f31b33515d39bb56c75fd8b26bef025ced7e
- https://git.kernel.org/stable/c/be8a0decd0b59a52a07276f9ef3b33ef820b2179
- https://git.kernel.org/stable/c/ebebeb58d48e25525fa654f2c53a24713fe141c3
- https://git.kernel.org/stable/c/ececf8eff6c25acc239fa8f0fd837c76bc770547
- https://git.kernel.org/stable/c/ef8b29398ea6061ac8257f3e45c9be45cc004ce2
- https://git.kernel.org/stable/c/fda8c491db2a90ff3e6fbbae58e495b4ddddeca3
Modified: 2025-04-29
CVE-2025-22056
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the
parsing logic should place every geneve_opt structure one by one
compactly. Hence, when deciding the next geneve_opt position, the
pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion
before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ==================================================================
[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70
[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178
[ 6.991162]
[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1
[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 6.992281] Call Trace:
[ 6.992423]
- https://git.kernel.org/stable/c/0a93a710d6df334b828ea064c6d39fda34f901dc
- https://git.kernel.org/stable/c/1b755d8eb1ace3870789d48fbd94f386ad6e30be
- https://git.kernel.org/stable/c/28d88ee1e1cc8ac2d79aeb112717b97c5c833d43
- https://git.kernel.org/stable/c/31d49eb436f2da61280508d7adf8c9b473b967aa
- https://git.kernel.org/stable/c/446d94898c560ed2f61e26ae445858a4c4830762
- https://git.kernel.org/stable/c/708e268acb3a446ad2a8a3d2e9bd41cc23660cd6
- https://git.kernel.org/stable/c/a263d31c8c92e5919d41af57d9479cfb66323782
- https://git.kernel.org/stable/c/ca2adfc03cd6273f0b589fe65afc6f75e0fe116e
Modified: 2025-04-29
CVE-2025-22063
In the Linux kernel, the following vulnerability has been resolved: netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.
- https://git.kernel.org/stable/c/078aabd567de3d63d37d7673f714e309d369e6e2
- https://git.kernel.org/stable/c/172a8a996a337206970467e871dd995ac07640b1
- https://git.kernel.org/stable/c/1927d0bcd5b81e80971bf6b8eba267508bd1c78b
- https://git.kernel.org/stable/c/1ad9166cab6a0f5c0b10344a97bdf749ae11dcbf
- https://git.kernel.org/stable/c/1e38f7a6cdd68377f8a4189b2fbaec14a6dd5152
- https://git.kernel.org/stable/c/3ba9cf69de50e8abed32b448616c313baa4c5712
- https://git.kernel.org/stable/c/797e5371cf55463b4530bab3fef5f27f7c6657a8
- https://git.kernel.org/stable/c/9fe3839588db7519030377b7dee3f165e654f6c5
- https://git.kernel.org/stable/c/a7e89541d05b98c79a51c0f95df020f8e82b62ed
Modified: 2025-04-29
CVE-2025-23136
In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: Add NULL check for adev Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. [ rjw: Subject edit, added Fixes: ]
- https://git.kernel.org/stable/c/0c49f12c77b77a706fd41370c11910635e491845
- https://git.kernel.org/stable/c/2542a3f70e563a9e70e7ded314286535a3321bdb
- https://git.kernel.org/stable/c/3155d5261b518776d1b807d9d922669991bbee56
- https://git.kernel.org/stable/c/6a810c462f099353e908c70619638884cb82229c
- https://git.kernel.org/stable/c/8e8f1ddf4186731649df8bc9646017369eb19186
- https://git.kernel.org/stable/c/953d28a4f459fcbde2d08f51aeca19d6b0f179f3
- https://git.kernel.org/stable/c/ac2eb7378319e3836cdf3a2c15a0bdf04c50e81d
- https://git.kernel.org/stable/c/bc7b5f782d28942dbdfda70df30ce132694a06de
- https://git.kernel.org/stable/c/d0d21c8e44216fa9afdb3809edf213f3c0a8c060
Modified: 2025-05-02
CVE-2025-37785
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir
entry with rec_len == block size results in out-of-bounds read (later
on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.'
and '..' as directory entries in the first data block. It first loads
the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()
and then uses its rec_len member to compute the location of '..' dir
entry (in ext4_next_entry). It assumes the '..' dir entry fits into the
same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the
sanity checks (it is considered the last directory entry in the data
block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the
memory slot allocated to the data block. The following call to
ext4_check_dir_entry() on new value of de then dereferences this pointer
which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir
entries that reach the end of data block. Make sure to ignore the phony
dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another
structure was recently freed from the slot past the bound, but it is
really an OOB read.
This issue was found by syzkaller tool.
Call Trace:
[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710
[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375
[ 38.595158]
[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1
[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 38.595304] Call Trace:
[ 38.595308]
- https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351
- https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842
- https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00
- https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93
- https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b
- https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78
- https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b
- https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353
- https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4
Modified: 2025-04-29
CVE-2025-39728
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix UBSAN panic in samsung_clk_init()
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to
dereferencing `ctx->clk_data.hws` before setting
`ctx->clk_data.num = nr_clks`. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
- https://git.kernel.org/stable/c/00307934eb94aaa0a99addfb37b9fe206f945004
- https://git.kernel.org/stable/c/0fef48f4a70e45a93e73c39023c3a6ea624714d6
- https://git.kernel.org/stable/c/157de9e48007a20c65d02fc0229a16f38134a72d
- https://git.kernel.org/stable/c/24307866e0ac0a5ddb462e766ceda5e27a6fbbe3
- https://git.kernel.org/stable/c/4d29a6dcb51e346595a15b49693eeb728925ca43
- https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf
- https://git.kernel.org/stable/c/d19d7345a7bcdb083b65568a11b11adffe0687af
- https://git.kernel.org/stable/c/d974e177369c034984cece9d7d4fada9f8b9c740
Modified: 2025-04-28
CVE-2025-39735
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.
- https://git.kernel.org/stable/c/0beddc2a3f9b9cf7d8887973041e36c2d0fa3652
- https://git.kernel.org/stable/c/16d3d36436492aa248b2d8045e75585ebcc2f34d
- https://git.kernel.org/stable/c/3d6fd5b9c6acbc005e53d0211c7381f566babec1
- https://git.kernel.org/stable/c/46e2c031aa59ea65128991cbca474bd5c0c2ecdb
- https://git.kernel.org/stable/c/50afcee7011155933d8d5e8832f52eeee018cfd3
- https://git.kernel.org/stable/c/5263822558a8a7c0d0248d5679c2dcf4d5cda61f
- https://git.kernel.org/stable/c/78c9cbde8880ec02d864c166bcb4fe989ce1d95f
- https://git.kernel.org/stable/c/a8c31808925b11393a6601f534bb63bac5366bab
- https://git.kernel.org/stable/c/fdf480da5837c23b146c4743c18de97202fcab37