ALT-PU-2025-6082-1
Package kernel-image-std-def updated to version 5.4.292-alt1 for branch p9 in task 381222.
Closed vulnerabilities
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-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-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-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