Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path<br /> <br /> Commit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") added<br /> a kref_get(&amp;gss_auth-&gt;kref) call to balance the gss_put_auth() done<br /> in gss_release_msg(), but forgot to add a corresponding kref_put()<br /> on the error path when kstrdup_const() fails.<br /> <br /> If service_name is non-NULL and kstrdup_const() fails, the function<br /> jumps to err_put_pipe_version which calls put_pipe_version() and<br /> kfree(gss_msg), but never releases the gss_auth reference. This leads<br /> to a kref leak where the gss_auth structure is never freed.<br /> <br /> Add a forward declaration for gss_free_callback() and call kref_put()<br /> in the err_put_pipe_version error path to properly release the<br /> reference taken earlier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: nau8821: Cancel delayed work on component remove<br /> <br /> Attempting to unload the driver while a jack detection work is pending<br /> would likely crash the kernel when it is eventually scheduled for<br /> execution:<br /> <br /> [ 1984.896308] BUG: unable to handle page fault for address: ffffffffc10c2a20<br /> [...]<br /> [ 1984.896388] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024<br /> [ 1984.896396] Workqueue: events nau8821_jdet_work [snd_soc_nau8821]<br /> [ 1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0<br /> [...]<br /> [ 1984.896504] Call Trace:<br /> [ 1984.896511] <br /> [ 1984.896524] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core]<br /> [ 1984.896572] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core]<br /> [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core]<br /> [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821]<br /> [ 1984.896636] process_one_work+0x211/0x590<br /> [ 1984.896649] ? srso_return_thunk+0x5/0x5f<br /> [ 1984.896670] worker_thread+0x1cd/0x3a0<br /> <br /> Cancel unscheduled jdet_work or wait for its execution to finish before<br /> the component driver gets removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: alb: fix UAF in rlb_arp_recv during bond up/down<br /> <br /> The ALB RX path may access rx_hashtbl concurrently with bond<br /> teardown. During rapid bond up/down cycles, rlb_deinitialize()<br /> frees rx_hashtbl while RX handlers are still running, leading<br /> to a null pointer dereference detected by KASAN.<br /> <br /> However, the root cause is that rlb_arp_recv() can still be accessed<br /> after setting recv_probe to NULL, which is actually a use-after-free<br /> (UAF) issue. That is the reason for using the referenced commit in the<br /> Fixes tag.<br /> <br /> [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI<br /> [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]<br /> [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)<br /> [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022<br /> [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding]<br /> [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 b6<br /> 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00<br /> [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206<br /> [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e<br /> [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8<br /> [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8<br /> [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119<br /> [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810<br /> [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000<br /> [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0<br /> [ 214.310347] Call Trace:<br /> [ 214.313070] <br /> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding]<br /> [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding]<br /> [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding]<br /> [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710<br /> [ 214.339199] ? __pfx_arp_process+0x10/0x10<br /> [ 214.343775] ? sched_balance_find_src_group+0x98/0x630<br /> [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10<br /> [ 214.356513] ? arp_rcv+0x307/0x690<br /> [ 214.360311] ? __pfx_arp_rcv+0x10/0x10<br /> [ 214.364499] ? __lock_acquire+0x58c/0xbd0<br /> [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0<br /> [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10<br /> [ 214.380743] ? lock_acquire+0x10b/0x140<br /> [ 214.385026] process_backlog+0x3f1/0x13a0<br /> [ 214.389502] ? process_backlog+0x3aa/0x13a0<br /> [ 214.394174] __napi_poll.constprop.0+0x9f/0x370<br /> [ 214.399233] net_rx_action+0x8c1/0xe60<br /> [ 214.403423] ? __pfx_net_rx_action+0x10/0x10<br /> [ 214.408193] ? lock_acquire.part.0+0xbd/0x260<br /> [ 214.413058] ? sched_clock_cpu+0x6c/0x540<br /> [ 214.417540] ? mark_held_locks+0x40/0x70<br /> [ 214.421920] handle_softirqs+0x1fd/0x860<br /> [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10<br /> [ 214.431264] ? __neigh_event_send+0x2d6/0xf50<br /> [ 214.436131] do_softirq+0xb1/0xf0<br /> [ 214.439830] <br /> <br /> The issue is reproducible by repeatedly running<br /> ip link set bond0 up/down while receiving ARP messages, where<br /> rlb_arp_recv() can race with rlb_deinitialize() and dereference<br /> a freed rx_hashtbl entry.<br /> <br /> Fix this by setting recv_probe to NULL and then calling<br /> synchronize_net() to wait for any concurrent RX processing to finish.<br /> This ensures that no RX handler can access rx_hashtbl after it is freed<br /> in bond_alb_deinitialize().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: playstation: Add missing check for input_ff_create_memless<br /> <br /> The ps_gamepad_create() function calls input_ff_create_memless()<br /> without verifying its return value, which can lead to incorrect<br /> behavior or potential crashes when FF effects are triggered.<br /> <br /> Add a check for the return value of input_ff_create_memless().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpuidle: Skip governor when only one idle state is available<br /> <br /> On certain platforms (PowerNV systems without a power-mgt DT node),<br /> cpuidle may register only a single idle state. In cases where that<br /> single state is a polling state (state 0), the ladder governor may<br /> incorrectly treat state 1 as the first usable state and pass an<br /> out-of-bounds index. This can lead to a NULL enter callback being<br /> invoked, ultimately resulting in a system crash.<br /> <br /> [ 13.342636] cpuidle-powernv : Only Snooze is available<br /> [ 13.351854] Faulting instruction address: 0x00000000<br /> [ 13.376489] NIP [0000000000000000] 0x0<br /> [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668<br /> <br /> Fix this by adding a bail-out in cpuidle_select() that returns state 0<br /> directly when state_count

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Return proper address for non-zero offsets in insn array<br /> <br /> The map_direct_value_addr() function of the instruction<br /> array map incorrectly adds offset to the resulting address.<br /> This is a bug, because later the resolve_pseudo_ldimm64()<br /> function adds the offset. Fix it. Corresponding selftests<br /> are added in a consequent commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix NULL pointer dereference in __unix_needs_revalidation<br /> <br /> When receiving file descriptors via SCM_RIGHTS, both the socket pointer<br /> and the socket&amp;#39;s sk pointer can be NULL during socket setup or teardown,<br /> causing NULL pointer dereferences in __unix_needs_revalidation().<br /> <br /> This is a regression in AppArmor 5.0.0 (kernel 6.17+) where the new<br /> __unix_needs_revalidation() function was added without proper NULL checks.<br /> <br /> The crash manifests as:<br /> BUG: kernel NULL pointer dereference, address: 0x0000000000000018<br /> RIP: aa_file_perm+0xb7/0x3b0 (or +0xbe/0x3b0, +0xc0/0x3e0)<br /> Call Trace:<br /> apparmor_file_receive+0x42/0x80<br /> security_file_receive+0x2e/0x50<br /> receive_fd+0x1d/0xf0<br /> scm_detach_fds+0xad/0x1c0<br /> <br /> The function dereferences sock-&gt;sk-&gt;sk_family without checking if either<br /> sock or sock-&gt;sk is NULL first.<br /> <br /> Add NULL checks for both sock and sock-&gt;sk before accessing sk_family.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix invalid deref of rawdata when export_binary is unset<br /> <br /> If the export_binary parameter is disabled on runtime, profiles that<br /> were loaded before that will still have their rawdata stored in<br /> apparmorfs, with a symbolic link to the rawdata on the policy<br /> directory. When one of those profiles are replaced, the rawdata is set<br /> to NULL, but when trying to resolve the symbolic links to rawdata for<br /> that profile, it will try to dereference profile-&gt;rawdata-&gt;name when<br /> profile-&gt;rawdata is now NULL causing an oops. Fix it by checking if<br /> rawdata is set.<br /> <br /> [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088<br /> [ 168.657420] #PF: supervisor read access in kernel mode<br /> [ 168.660619] #PF: error_code(0x0000) - not-present page<br /> [ 168.663613] PGD 0 P4D 0<br /> [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)<br /> [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330<br /> [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8<br /> [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282<br /> [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158<br /> [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80<br /> [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80<br /> [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0<br /> [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000<br /> [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0<br /> [ 168.701696] Call Trace:<br /> [ 168.702325] <br /> [ 168.702995] rawdata_get_link_data+0x1c/0x30<br /> [ 168.704145] vfs_readlink+0xd4/0x160<br /> [ 168.705152] do_readlinkat+0x114/0x180<br /> [ 168.706214] __x64_sys_readlink+0x1e/0x30<br /> [ 168.708653] x64_sys_call+0x1d77/0x26b0<br /> [ 168.709525] do_syscall_64+0x81/0x500<br /> [ 168.710348] ? do_statx+0x72/0xb0<br /> [ 168.711109] ? putname+0x3e/0x80<br /> [ 168.711845] ? __x64_sys_statx+0xb7/0x100<br /> [ 168.712711] ? x64_sys_call+0x10fc/0x26b0<br /> [ 168.713577] ? do_syscall_64+0xbf/0x500<br /> [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0<br /> [ 168.715404] ? irqentry_exit+0xb2/0x740<br /> [ 168.716359] ? exc_page_fault+0x90/0x1b0<br /> [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: Validate SQE128 flag before accessing the cmd<br /> <br /> ublk_ctrl_cmd_dump() accesses (header *)sqe-&gt;cmd before<br /> IO_URING_F_SQE128 flag check. This could cause out of boundary memory<br /> access.<br /> <br /> Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return<br /> -EINVAL immediately if the flag is not set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: fix memory leaks in gfs2_fill_super error path<br /> <br /> Fix two memory leaks in the gfs2_fill_super() error handling path when<br /> transitioning a filesystem to read-write mode fails.<br /> <br /> First leak: kthread objects (thread_struct, task_struct, etc.)<br /> When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the<br /> created kernel threads (logd and quotad) are never destroyed. This<br /> occurs because the fail_per_node label doesn&amp;#39;t call<br /> gfs2_destroy_threads().<br /> <br /> Second leak: quota bitmap buffer (8192 bytes)<br /> When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but<br /> before other operations complete, the allocated quota bitmap is never<br /> freed.<br /> <br /> The fix moves thread cleanup to the fail_per_node label to handle all<br /> error paths uniformly. gfs2_destroy_threads() is safe to call<br /> unconditionally as it checks for NULL pointers. Quota cleanup is added<br /> in gfs2_make_fs_rw() to properly handle the withdrawal case where<br /> quota initialization succeeds but the filesystem is then withdrawn.<br /> <br /> Thread leak backtrace (gfs2_freeze_lock_shared failure):<br /> unreferenced object 0xffff88801d7bca80 (size 4480):<br /> copy_process+0x3a1/0x4670 kernel/fork.c:2422<br /> kernel_clone+0xf3/0x6e0 kernel/fork.c:2779<br /> kthread_create_on_node+0x100/0x150 kernel/kthread.c:478<br /> init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611<br /> gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265<br /> <br /> Quota leak backtrace (gfs2_make_fs_rw failure):<br /> unreferenced object 0xffff88812de7c000 (size 8192):<br /> gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409<br /> gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149<br /> gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: return error when node already exists in hfs_bnode_create<br /> <br /> When hfs_bnode_create() finds that a node is already hashed (which should<br /> not happen in normal operation), it currently returns the existing node<br /> without incrementing its reference count. This causes a reference count<br /> inconsistency that leads to a kernel panic when the node is later freed<br /> in hfs_bnode_put():<br /> <br /> kernel BUG at fs/hfsplus/bnode.c:676!<br /> BUG_ON(!atomic_read(&amp;node-&gt;refcnt))<br /> <br /> This scenario can occur when hfs_bmap_alloc() attempts to allocate a node<br /> that is already in use (e.g., when node 0&amp;#39;s bitmap bit is incorrectly<br /> unset), or due to filesystem corruption.<br /> <br /> Returning an existing node from a create path is not normal operation.<br /> <br /> Fix this by returning ERR_PTR(-EEXIST) instead of the node when it&amp;#39;s<br /> already hashed. This properly signals the error condition to callers,<br /> which already check for IS_ERR() return values.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix a crash due to incorrect cleanup usage of kfree<br /> <br /> Annotating a local pointer variable, which will be assigned with the<br /> kmalloc-family functions, with the `__cleanup(kfree)` attribute will<br /> make the address of the local variable, rather than the address returned<br /> by kmalloc, passed to kfree directly and lead to a crash due to invalid<br /> deallocation of stack address. According to other places in the repo,<br /> the correct usage should be `__free(kfree)`. The code coincidentally<br /> compiled because the parameter type `void *` of kfree is compatible with<br /> the desired type `struct { ... } **`.