Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs<br /> <br /> The hns3 driver define an array of string to show the coalesce<br /> info, but if the kernel adds a new mode or a new state,<br /> out-of-bounds access may occur when coalesce info is read via<br /> debugfs, this patch fix the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs<br /> <br /> If init debugfs failed during device registration due to memory allocation<br /> failure, debugfs_remove_recursive() is called, after which debugfs_dir is<br /> not set to NULL. debugfs_remove_recursive() will be called again during<br /> device removal. As a result, illegal pointer is accessed.<br /> <br /> [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!<br /> ...<br /> [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 1669.872669] pc : down_write+0x24/0x70<br /> [ 1669.876315] lr : down_write+0x1c/0x70<br /> [ 1669.879961] sp : ffff000036f53a30<br /> [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8<br /> [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000<br /> [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270<br /> [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8<br /> [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310<br /> [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10<br /> [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000<br /> [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870<br /> [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228<br /> [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0<br /> [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10<br /> [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff<br /> [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00<br /> [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000<br /> [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001<br /> [ 1669.962563] Call trace:<br /> [ 1669.965000] down_write+0x24/0x70<br /> [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0<br /> [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]<br /> [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]<br /> [ 1669.984175] pci_device_remove+0x48/0xd8<br /> [ 1669.988082] device_release_driver_internal+0x1b4/0x250<br /> [ 1669.993282] device_release_driver+0x28/0x38<br /> [ 1669.997534] pci_stop_bus_device+0x84/0xb8<br /> [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40<br /> [ 1670.007244] remove_store+0xfc/0x140<br /> [ 1670.010802] dev_attr_store+0x44/0x60<br /> [ 1670.014448] sysfs_kf_write+0x58/0x80<br /> [ 1670.018095] kernfs_fop_write+0xe8/0x1f0<br /> [ 1670.022000] __vfs_write+0x60/0x190<br /> [ 1670.025472] vfs_write+0xac/0x1c0<br /> [ 1670.028771] ksys_write+0x6c/0xd8<br /> [ 1670.032071] __arm64_sys_write+0x24/0x30<br /> [ 1670.035977] el0_svc_common+0x78/0x130<br /> [ 1670.039710] el0_svc_handler+0x38/0x78<br /> [ 1670.043442] el0_svc+0x8/0xc<br /> <br /> To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()<br /> <br /> fc_lport_ptp_setup() did not check the return value of fc_rport_create()<br /> which can return NULL and would cause a NULL pointer dereference. Address<br /> this issue by checking return value of fc_rport_create() and log error<br /> message on fc_rport_create() failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: Add check for negative db_l2nbperpage<br /> <br /> l2nbperpage is log2(number of blks per page), and the minimum legal<br /> value should be 0, not negative.<br /> <br /> In the case of l2nbperpage being negative, an error will occur<br /> when subsequently used as shift exponent.<br /> <br /> Syzbot reported this bug:<br /> <br /> UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12<br /> shift exponent -16777216 is negative

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool<br /> <br /> In practice the driver should never send more commands than are allocated<br /> to a queue&amp;#39;s event pool. In the unlikely event that this happens, the code<br /> asserts a BUG_ON, and in the case that the kernel is not configured to<br /> crash on panic returns a junk event pointer from the empty event list<br /> causing things to spiral from there. This BUG_ON is a historical artifact<br /> of the ibmvfc driver first being upstreamed, and it is well known now that<br /> the use of BUG_ON is bad practice except in the most unrecoverable<br /> scenario. There is nothing about this scenario that prevents the driver<br /> from recovering and carrying on.<br /> <br /> Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL<br /> pointer in the case of an empty event pool. Update all call sites to<br /> ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate<br /> failure or recovery action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: pcrypt - Fix hungtask for PADATA_RESET<br /> <br /> We found a hungtask bug in test_aead_vec_cfg as follows:<br /> <br /> INFO: task cryptomgr_test:391009 blocked for more than 120 seconds.<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> Call trace:<br /> __switch_to+0x98/0xe0<br /> __schedule+0x6c4/0xf40<br /> schedule+0xd8/0x1b4<br /> schedule_timeout+0x474/0x560<br /> wait_for_common+0x368/0x4e0<br /> wait_for_completion+0x20/0x30<br /> wait_for_completion+0x20/0x30<br /> test_aead_vec_cfg+0xab4/0xd50<br /> test_aead+0x144/0x1f0<br /> alg_test_aead+0xd8/0x1e0<br /> alg_test+0x634/0x890<br /> cryptomgr_test+0x40/0x70<br /> kthread+0x1e0/0x220<br /> ret_from_fork+0x10/0x18<br /> Kernel panic - not syncing: hung_task: blocked tasks<br /> <br /> For padata_do_parallel, when the return err is 0 or -EBUSY, it will call<br /> wait_for_completion(&amp;wait-&gt;completion) in test_aead_vec_cfg. In normal<br /> case, aead_request_complete() will be called in pcrypt_aead_serial and the<br /> return err is 0 for padata_do_parallel. But, when pinst-&gt;flags is<br /> PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it<br /> won&amp;#39;t call aead_request_complete(). Therefore, test_aead_vec_cfg will<br /> hung at wait_for_completion(&amp;wait-&gt;completion), which will cause<br /> hungtask.<br /> <br /> The problem comes as following:<br /> (padata_do_parallel) |<br /> rcu_read_lock_bh(); |<br /> err = -EINVAL; | (padata_replace)<br /> | pinst-&gt;flags |= PADATA_RESET;<br /> err = -EBUSY |<br /> if (pinst-&gt;flags &amp; PADATA_RESET) |<br /> rcu_read_unlock_bh() |<br /> return err<br /> <br /> In order to resolve the problem, we replace the return err -EBUSY with<br /> -EAGAIN, which means parallel_data is changing, and the caller should call<br /> it again.<br /> <br /> v3:<br /> remove retry and just change the return err.<br /> v2:<br /> introduce padata_try_do_parallel() in pcrypt_aead_encrypt and<br /> pcrypt_aead_decrypt to solve the hungtask.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix potential null pointer derefernce<br /> <br /> The amdgpu_ras_get_context may return NULL if device<br /> not support ras feature, so add check before using.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vkms: fix a possible null pointer dereference<br /> <br /> In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode()<br /> is assigned to mode, which will lead to a NULL pointer dereference<br /> on failure of drm_cvt_mode(). Add a check to avoid null pointer<br /> dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix shift out-of-bounds issue<br /> <br /> [ 567.613292] shift exponent 255 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> [ 567.614498] CPU: 5 PID: 238 Comm: kworker/5:1 Tainted: G OE 6.2.0-34-generic #34~22.04.1-Ubuntu<br /> [ 567.614502] Hardware name: AMD Splinter/Splinter-RPL, BIOS WS43927N_871 09/25/2023<br /> [ 567.614504] Workqueue: events send_exception_work_handler [amdgpu]<br /> [ 567.614748] Call Trace:<br /> [ 567.614750] <br /> [ 567.614753] dump_stack_lvl+0x48/0x70<br /> [ 567.614761] dump_stack+0x10/0x20<br /> [ 567.614763] __ubsan_handle_shift_out_of_bounds+0x156/0x310<br /> [ 567.614769] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 567.614773] ? update_sd_lb_stats.constprop.0+0xf2/0x3c0<br /> [ 567.614780] svm_range_split_by_granularity.cold+0x2b/0x34 [amdgpu]<br /> [ 567.615047] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 567.615052] svm_migrate_to_ram+0x185/0x4d0 [amdgpu]<br /> [ 567.615286] do_swap_page+0x7b6/0xa30<br /> [ 567.615291] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 567.615294] ? __free_pages+0x119/0x130<br /> [ 567.615299] handle_pte_fault+0x227/0x280<br /> [ 567.615303] __handle_mm_fault+0x3c0/0x720<br /> [ 567.615311] handle_mm_fault+0x119/0x330<br /> [ 567.615314] ? lock_mm_and_find_vma+0x44/0x250<br /> [ 567.615318] do_user_addr_fault+0x1a9/0x640<br /> [ 567.615323] exc_page_fault+0x81/0x1b0<br /> [ 567.615328] asm_exc_page_fault+0x27/0x30<br /> [ 567.615332] RIP: 0010:__get_user_8+0x1c/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL<br /> <br /> In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:<br /> <br /> 1. Navigate to the directory: /sys/kernel/debug/dri/0<br /> 2. Execute command: cat amdgpu_regs_smc<br /> 3. Exception Log::<br /> [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [4005007.702562] #PF: supervisor instruction fetch in kernel mode<br /> [4005007.702567] #PF: error_code(0x0010) - not-present page<br /> [4005007.702570] PGD 0 P4D 0<br /> [4005007.702576] Oops: 0010 [#1] SMP NOPTI<br /> [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u<br /> [4005007.702590] RIP: 0010:0x0<br /> [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.<br /> [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206<br /> [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68<br /> [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000<br /> [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980<br /> [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000<br /> [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000<br /> [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000<br /> [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0<br /> [4005007.702633] Call Trace:<br /> [4005007.702636] <br /> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]<br /> [4005007.703002] full_proxy_read+0x5c/0x80<br /> [4005007.703011] vfs_read+0x9f/0x1a0<br /> [4005007.703019] ksys_read+0x67/0xe0<br /> [4005007.703023] __x64_sys_read+0x19/0x20<br /> [4005007.703028] do_syscall_64+0x5c/0xc0<br /> [4005007.703034] ? do_user_addr_fault+0x1e3/0x670<br /> [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0<br /> [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20<br /> [4005007.703052] ? irqentry_exit+0x19/0x30<br /> [4005007.703057] ? exc_page_fault+0x89/0x160<br /> [4005007.703062] ? asm_exc_page_fault+0x8/0x30<br /> [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [4005007.703075] RIP: 0033:0x7f5e07672992<br /> [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24<br /> [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992<br /> [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003<br /> [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010<br /> [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000<br /> [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000<br /> [4005007.703105] <br /> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca<br /> [4005007.703184] CR2: 0000000000000000<br /> [4005007.703188] ---[ en<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7<br /> <br /> For pptable structs that use flexible array sizes, use flexible arrays.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga<br /> <br /> For pptable structs that use flexible array sizes, use flexible arrays.