Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdgpu: fix potential memleak<br /> <br /> In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed<br /> There is a potential memleak if not call kobject_put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again<br /> <br /> In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch<br /> already been called, the start_cpsch will not be called since there is no resume in this<br /> case. When reset been triggered again, driver should avoid to do uninitialization again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_mode<br /> <br /> Fix the following NULL pointer dereference in mt7915_get_phy_mode<br /> routine adding an ibss interface to the mt7915 driver.<br /> <br /> [ 101.137097] wlan0: Trigger new scan to find an IBSS to join<br /> [ 102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69<br /> [ 103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 103.073670] Mem abort info:<br /> [ 103.076520] ESR = 0x96000005<br /> [ 103.079614] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 103.084934] SET = 0, FnV = 0<br /> [ 103.088042] EA = 0, S1PTW = 0<br /> [ 103.091215] Data abort info:<br /> [ 103.094104] ISV = 0, ISS = 0x00000005<br /> [ 103.098041] CM = 0, WnR = 0<br /> [ 103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000<br /> [ 103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 103.116590] Internal error: Oops: 96000005 [#1] SMP<br /> [ 103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0<br /> [ 103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT)<br /> [ 103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211]<br /> [ 103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)<br /> [ 103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e]<br /> [ 103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e]<br /> [ 103.223927] sp : ffffffc011cdb9e0<br /> [ 103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098<br /> [ 103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40<br /> [ 103.237855] x25: 0000000000000001 x24: 000000000000011f<br /> [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918<br /> [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58<br /> [ 103.253785] x19: ffffff8006744400 x18: 0000000000000000<br /> [ 103.259094] x17: 0000000000000000 x16: 0000000000000001<br /> [ 103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8<br /> [ 103.269713] x13: 0000000000000000 x12: 0000000000000000<br /> [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000<br /> [ 103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88<br /> [ 103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44<br /> [ 103.290952] x5 : 0000000000000002 x4 : 0000000000000001<br /> [ 103.296262] x3 : 0000000000000001 x2 : 0000000000000001<br /> [ 103.301572] x1 : 0000000000000000 x0 : 0000000000000011<br /> [ 103.306882] Call trace:<br /> [ 103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e]<br /> [ 103.314378] mt7915_bss_info_changed+0x198/0x200 [mt7915e]<br /> [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211]<br /> [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211]<br /> [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211]<br /> [ 103.337895] ieee80211_ibss_work+0x3dc/0x614 [mac80211]<br /> [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211]<br /> [ 103.348495] process_one_work+0x288/0x690<br /> [ 103.352499] worker_thread+0x70/0x464<br /> [ 103.356157] kthread+0x144/0x150<br /> [ 103.359380] ret_from_fork+0x10/0x18<br /> [ 103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()<br /> <br /> In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and<br /> tmp-&gt;tx_cq will be freed on the error path of mlx4_en_copy_priv().<br /> After that mlx4_en_alloc_resources() is called and there is a dereference<br /> of &amp;tmp-&gt;tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to<br /> a use after free problem on failure of mlx4_en_copy_priv().<br /> <br /> Fix this bug by adding a check of mlx4_en_copy_priv()<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_MLX4_EN=m show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()<br /> <br /> In qlcnic_83xx_add_rings(), the indirect function of<br /> ahw-&gt;hw_ops-&gt;alloc_mbx_args will be called to allocate memory for<br /> cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),<br /> which could lead to a NULL pointer dereference on failure of the<br /> indirect function like qlcnic_83xx_alloc_mbx_args().<br /> <br /> Fix this bug by adding a check of alloc_mbx_args(), this patch<br /> imitates the logic of mbx_cmd()&amp;#39;s failure handling.<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_QLCNIC=m show no new warnings, and our<br /> static analyzer no longer warns about this code.

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 /> tcp: fix page frag corruption on page fault<br /> <br /> Steffen reported a TCP stream corruption for HTTP requests<br /> served by the apache web-server using a cifs mount-point<br /> and memory mapping the relevant file.<br /> <br /> The root cause is quite similar to the one addressed by<br /> commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from<br /> memory reclaim"). Here the nested access to the task page frag<br /> is caused by a page fault on the (mmapped) user-space memory<br /> buffer coming from the cifs file.<br /> <br /> The page fault handler performs an smb transaction on a different<br /> socket, inside the same process context. Since sk-&gt;sk_allaction<br /> for such socket does not prevent the usage for the task_frag,<br /> the nested allocation modify "under the hood" the page frag<br /> in use by the outer sendmsg call, corrupting the stream.<br /> <br /> The overall relevant stack trace looks like the following:<br /> <br /> httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:<br /> ffffffff91461d91 tcp_sendmsg_locked+0x1<br /> ffffffff91462b57 tcp_sendmsg+0x27<br /> ffffffff9139814e sock_sendmsg+0x3e<br /> ffffffffc06dfe1d smb_send_kvec+0x28<br /> [...]<br /> ffffffffc06cfaf8 cifs_readpages+0x213<br /> ffffffff90e83c4b read_pages+0x6b<br /> ffffffff90e83f31 __do_page_cache_readahead+0x1c1<br /> ffffffff90e79e98 filemap_fault+0x788<br /> ffffffff90eb0458 __do_fault+0x38<br /> ffffffff90eb5280 do_fault+0x1a0<br /> ffffffff90eb7c84 __handle_mm_fault+0x4d4<br /> ffffffff90eb8093 handle_mm_fault+0xc3<br /> ffffffff90c74f6d __do_page_fault+0x1ed<br /> ffffffff90c75277 do_page_fault+0x37<br /> ffffffff9160111e page_fault+0x1e<br /> ffffffff9109e7b5 copyin+0x25<br /> ffffffff9109eb40 _copy_from_iter_full+0xe0<br /> ffffffff91462370 tcp_sendmsg_locked+0x5e0<br /> ffffffff91462370 tcp_sendmsg_locked+0x5e0<br /> ffffffff91462b57 tcp_sendmsg+0x27<br /> ffffffff9139815c sock_sendmsg+0x4c<br /> ffffffff913981f7 sock_write_iter+0x97<br /> ffffffff90f2cc56 do_iter_readv_writev+0x156<br /> ffffffff90f2dff0 do_iter_write+0x80<br /> ffffffff90f2e1c3 vfs_writev+0xa3<br /> ffffffff90f2e27c do_writev+0x5c<br /> ffffffff90c042bb do_syscall_64+0x5b<br /> ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65<br /> <br /> The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,<br /> we can avoid the nesting using the sk page frag for allocation<br /> lacking the __GFP_FS flag. Do not define an additional mm-helper<br /> for that, as this is strictly tied to the sk page frag usage.<br /> <br /> v1 -&gt; v2:<br /> - use a stricted sk_page_frag() check instead of reordering the<br /> code (Eric)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Allocate enough space for GMU registers<br /> <br /> In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for<br /> A650") we changed a6xx_get_gmu_registers() to read 3 sets of<br /> registers. Unfortunately, we didn&amp;#39;t change the memory allocation for<br /> the array. That leads to a KASAN warning (this was on the chromeos-5.4<br /> kernel, which has the problematic commit backported to it):<br /> <br /> BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430<br /> Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209<br /> CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22<br /> Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x248<br /> show_stack+0x20/0x2c<br /> dump_stack+0x128/0x1ec<br /> print_address_description+0x88/0x4a0<br /> __kasan_report+0xfc/0x120<br /> kasan_report+0x10/0x18<br /> __asan_report_store8_noabort+0x1c/0x24<br /> _a6xx_get_gmu_registers+0x144/0x430<br /> a6xx_gpu_state_get+0x330/0x25d4<br /> msm_gpu_crashstate_capture+0xa0/0x84c<br /> recover_worker+0x328/0x838<br /> kthread_worker_fn+0x32c/0x574<br /> kthread+0x2dc/0x39c<br /> ret_from_fork+0x10/0x18<br /> <br /> Allocated by task 209:<br /> __kasan_kmalloc+0xfc/0x1c4<br /> kasan_kmalloc+0xc/0x14<br /> kmem_cache_alloc_trace+0x1f0/0x2a0<br /> a6xx_gpu_state_get+0x164/0x25d4<br /> msm_gpu_crashstate_capture+0xa0/0x84c<br /> recover_worker+0x328/0x838<br /> kthread_worker_fn+0x32c/0x574<br /> kthread+0x2dc/0x39c<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix wrong list_del in smc_lgr_cleanup_early<br /> <br /> smc_lgr_cleanup_early() meant to delete the link<br /> group from the link group list, but it deleted<br /> the list head by mistake.<br /> <br /> This may cause memory corruption since we didn&amp;#39;t<br /> remove the real link group from the list and later<br /> memseted the link group structure.<br /> We got a list corruption panic when testing:<br /> <br /> [  231.277259] list_del corruption. prev-&gt;next should be ffff8881398a8000, but was 0000000000000000<br /> [  231.278222] ------------[ cut here ]------------<br /> [  231.278726] kernel BUG at lib/list_debug.c:53!<br /> [  231.279326] invalid opcode: 0000 [#1] SMP NOPTI<br /> [  231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435<br /> [  231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014<br /> [  231.281248] Workqueue: events smc_link_down_work<br /> [  231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90<br /> [  231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c<br /> 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <br /> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc<br /> [  231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292<br /> [  231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000<br /> [  231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040<br /> [  231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001<br /> [  231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001<br /> [  231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003<br /> [  231.288337] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> [  231.289160] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [  231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0<br /> [  231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [  231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [  231.291940] Call Trace:<br /> [  231.292211]  smc_lgr_terminate_sched+0x53/0xa0<br /> [  231.292677]  smc_switch_conns+0x75/0x6b0<br /> [  231.293085]  ? update_load_avg+0x1a6/0x590<br /> [  231.293517]  ? ttwu_do_wakeup+0x17/0x150<br /> [  231.293907]  ? update_load_avg+0x1a6/0x590<br /> [  231.294317]  ? newidle_balance+0xca/0x3d0<br /> [  231.294716]  smcr_link_down+0x50/0x1a0<br /> [  231.295090]  ? __wake_up_common_lock+0x77/0x90<br /> [  231.295534]  smc_link_down_work+0x46/0x60<br /> [  231.295933]  process_one_work+0x18b/0x350

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Fix a memleak bug in rvu_mbox_init()<br /> <br /> In rvu_mbox_init(), mbox_regions is not freed or passed out<br /> under the switch-default region, which could lead to a memory leak.<br /> <br /> Fix this bug by changing &amp;#39;return err&amp;#39; to &amp;#39;goto free_regions&amp;#39;.<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_OCTEONTX2_AF=y show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()<br /> <br /> Need to call rxrpc_put_local() for peer candidate before kfree() as it<br /> holds a ref to rxrpc_local.<br /> <br /> [DH: v2: Changed to abstract the peer freeing code out into a function]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle()<br /> <br /> Need to call rxrpc_put_peer() for bundle candidate before kfree() as it<br /> holds a ref to rxrpc_peer.<br /> <br /> [DH: v2: Changed to abstract out the bundle freeing code into a function]