Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel: powerclamp: fix mismatch in get function for max_idle<br /> <br /> KASAN reported this<br /> <br /> [ 444.853098] BUG: KASAN: global-out-of-bounds in param_get_int+0x77/0x90<br /> [ 444.853111] Read of size 4 at addr ffffffffc16c9220 by task cat/2105<br /> ...<br /> [ 444.853442] The buggy address belongs to the variable:<br /> [ 444.853443] max_idle+0x0/0xffffffffffffcde0 [intel_powerclamp]<br /> <br /> There is a mismatch between the param_get_int and the definition of<br /> max_idle. Replacing param_get_int with param_get_byte resolves this<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-vdpa: fix use after free in vhost_vdpa_probe()<br /> <br /> The put_device() calls vhost_vdpa_release_dev() which calls<br /> ida_simple_remove() and frees "v". So this call to<br /> ida_simple_remove() is a use after free and a double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: add ipvlan_route_v6_outbound() helper<br /> <br /> Inspired by syzbot reports using a stack of multiple ipvlan devices.<br /> <br /> Reduce stack size needed in ipvlan_process_v6_outbound() by moving<br /> the flowi6 struct used for the route lookup in an non inlined<br /> helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,<br /> immediately reclaimed.<br /> <br /> Also make sure ipvlan_process_v4_outbound() is not inlined.<br /> <br /> We might also have to lower MAX_NEST_DEV, because only syzbot uses<br /> setups with more than four stacked devices.<br /> <br /> BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)<br /> stack guard page: 0000 [#1] SMP KASAN<br /> CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023<br /> RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188<br /> Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89<br /> RSP: 0018:ffffc9000e804000 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2<br /> RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568<br /> RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c<br /> R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000<br /> FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> [] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31<br /> [] instrument_atomic_read include/linux/instrumented.h:72 [inline]<br /> [] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]<br /> [] cpumask_test_cpu include/linux/cpumask.h:506 [inline]<br /> [] cpu_online include/linux/cpumask.h:1092 [inline]<br /> [] trace_lock_acquire include/trace/events/lock.h:24 [inline]<br /> [] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632<br /> [] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306<br /> [] rcu_read_lock include/linux/rcupdate.h:747 [inline]<br /> [] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221<br /> [] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606<br /> [] pol_lookup_func include/net/ip6_fib.h:584 [inline]<br /> [] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116<br /> [] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638<br /> [] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651<br /> [] ip6_route_output include/net/ip6_route.h:100 [inline]<br /> [] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]<br /> [] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]<br /> [] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]<br /> [] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677<br /> [] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229<br /> [] netdev_start_xmit include/linux/netdevice.h:4966 [inline]<br /> [] xmit_one net/core/dev.c:3644 [inline]<br /> [] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660<br /> [] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324<br /> [] dev_queue_xmit include/linux/netdevice.h:3067 [inline]<br /> [] neigh_hh_output include/net/neighbour.h:529 [inline]<br /> [

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: Check find_first_bit() return value<br /> <br /> We must check the return value of find_first_bit() before using the<br /> return value as an index array since it happens to overflow the array<br /> and then panic:<br /> <br /> [ 107.318430] Kernel BUG [#1]<br /> [ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2<br /> [ 107.319465] Hardware name: riscv-virtio,qemu (DT)<br /> [ 107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae<br /> [ 107.319840] ra : pmu_sbi_ovf_handler+0x52/0x3ae<br /> [ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350<br /> [ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480<br /> [ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520<br /> [ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff<br /> [ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000<br /> [ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55<br /> [ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f<br /> [ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000<br /> [ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0<br /> [ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000<br /> [ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000<br /> [ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 107.320081] [] pmu_sbi_ovf_handler+0x3a4/0x3ae<br /> [ 107.320112] [] handle_percpu_devid_irq+0x9e/0x1a0<br /> [ 107.320131] [] generic_handle_domain_irq+0x28/0x36<br /> [ 107.320148] [] riscv_intc_irq+0x36/0x4e<br /> [ 107.320166] [] handle_riscv_irq+0x54/0x86<br /> [ 107.320189] [] do_irq+0x64/0x96<br /> [ 107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097<br /> [ 107.320585] ---[ end trace 0000000000000000 ]---<br /> [ 107.320704] Kernel panic - not syncing: Fatal exception in interrupt<br /> [ 107.320775] SMP: stopping secondary CPUs<br /> [ 107.321219] Kernel Offset: 0x0 from 0xffffffff80000000<br /> [ 107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix dfs radar event locking<br /> <br /> The ath11k active pdevs are protected by RCU but the DFS radar event<br /> handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a<br /> read-side critical section.<br /> <br /> Mark the code in question as an RCU read-side critical section to avoid<br /> any potential use-after-free issues.<br /> <br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in dbFindLeaf<br /> <br /> Currently while searching for dmtree_t for sufficient free blocks there<br /> is an array out of bounds while getting element in tp-&gt;dm_stree. To add<br /> the required check for out of bound we first need to determine the type<br /> of dmtree. Thus added an extra parameter to dbFindLeaf so that the type<br /> of tree can be determined and the required check can be applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix htt pktlog locking<br /> <br /> The ath11k active pdevs are protected by RCU but the htt pktlog handling<br /> code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a<br /> read-side critical section.<br /> <br /> Mark the code in question as an RCU read-side critical section to avoid<br /> any potential use-after-free issues.<br /> <br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix missing update of domains_itree after splitting iopt_area<br /> <br /> In iopt_area_split(), if the original iopt_area has filled a domain and is<br /> linked to domains_itree, pages_nodes have to be properly<br /> reinserted. Otherwise the domains_itree becomes corrupted and we will UAF.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix RPC client cleaned up the freed pipefs dentries<br /> <br /> RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()<br /> workqueue,which takes care about pipefs superblock locking.<br /> In some special scenarios, when kernel frees the pipefs sb of the<br /> current client and immediately alloctes a new pipefs sb,<br /> rpc_remove_pipedir function would misjudge the existence of pipefs<br /> sb which is not the one it used to hold. As a result,<br /> the rpc_remove_pipedir would clean the released freed pipefs dentries.<br /> <br /> To fix this issue, rpc_remove_pipedir should check whether the<br /> current pipefs sb is consistent with the original pipefs sb.<br /> <br /> This error can be catched by KASAN:<br /> =========================================================<br /> [ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200<br /> [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503<br /> [ 250.500549] Workqueue: events rpc_free_client_work<br /> [ 250.501001] Call Trace:<br /> [ 250.502880] kasan_report+0xb6/0xf0<br /> [ 250.503209] ? dget_parent+0x195/0x200<br /> [ 250.503561] dget_parent+0x195/0x200<br /> [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10<br /> [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90<br /> [ 250.504781] rpc_remove_client_dir+0xf5/0x150<br /> [ 250.505195] rpc_free_client_work+0xe4/0x230<br /> [ 250.505598] process_one_work+0x8ee/0x13b0<br /> ...<br /> [ 22.039056] Allocated by task 244:<br /> [ 22.039390] kasan_save_stack+0x22/0x50<br /> [ 22.039758] kasan_set_track+0x25/0x30<br /> [ 22.040109] __kasan_slab_alloc+0x59/0x70<br /> [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240<br /> [ 22.040889] __d_alloc+0x31/0x8e0<br /> [ 22.041207] d_alloc+0x44/0x1f0<br /> [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140<br /> [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110<br /> [ 22.042459] rpc_create_client_dir+0x34/0x150<br /> [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0<br /> [ 22.043284] rpc_client_register+0x136/0x4e0<br /> [ 22.043689] rpc_new_client+0x911/0x1020<br /> [ 22.044057] rpc_create_xprt+0xcb/0x370<br /> [ 22.044417] rpc_create+0x36b/0x6c0<br /> ...<br /> [ 22.049524] Freed by task 0:<br /> [ 22.049803] kasan_save_stack+0x22/0x50<br /> [ 22.050165] kasan_set_track+0x25/0x30<br /> [ 22.050520] kasan_save_free_info+0x2b/0x50<br /> [ 22.050921] __kasan_slab_free+0x10e/0x1a0<br /> [ 22.051306] kmem_cache_free+0xa5/0x390<br /> [ 22.051667] rcu_core+0x62c/0x1930<br /> [ 22.051995] __do_softirq+0x165/0x52a<br /> [ 22.052347]<br /> [ 22.052503] Last potentially related work creation:<br /> [ 22.052952] kasan_save_stack+0x22/0x50<br /> [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0<br /> [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0<br /> [ 22.054209] dentry_free+0xb2/0x140<br /> [ 22.054540] __dentry_kill+0x3be/0x540<br /> [ 22.054900] shrink_dentry_list+0x199/0x510<br /> [ 22.055293] shrink_dcache_parent+0x190/0x240<br /> [ 22.055703] do_one_tree+0x11/0x40<br /> [ 22.056028] shrink_dcache_for_umount+0x61/0x140<br /> [ 22.056461] generic_shutdown_super+0x70/0x590<br /> [ 22.056879] kill_anon_super+0x3a/0x60<br /> [ 22.057234] rpc_kill_sb+0x121/0x200

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: Add validity check for db_maxag and db_agpref<br /> <br /> Both db_maxag and db_agpref are used as the index of the<br /> db_agfree array, but there is currently no validity check for<br /> db_maxag and db_agpref, which can lead to errors.<br /> <br /> The following is related bug reported by Syzbot:<br /> <br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20<br /> index 7936 is out of range for type &amp;#39;atomic_t[128]&amp;#39;<br /> <br /> Add checking that the values of db_maxag and db_agpref are valid<br /> indexes for the db_agfree array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in diAlloc<br /> <br /> Currently there is not check against the agno of the iag while<br /> allocating new inodes to avoid fragmentation problem. Added the check<br /> which is required.