Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid reading out of bounds when loading TX power FW elements<br /> <br /> Because the loop-expression will do one more time before getting false from<br /> cond-expression, the original code copied one more entry size beyond valid<br /> region.<br /> <br /> Fix it by moving the entry copy to loop-body.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: efifb: Register sysfs groups through driver core<br /> <br /> The driver core can register and cleanup sysfs groups already.<br /> Make use of that functionality to simplify the error handling and<br /> cleanup.<br /> <br /> Also avoid a UAF race during unregistering where the sysctl attributes<br /> were usable after the info struct was freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: avoid NULL pointer dereference<br /> <br /> iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta<br /> pointer is not NULL.<br /> It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is<br /> dereferencing the ieee80211_sta pointer.<br /> If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL<br /> pointer.<br /> Fix this by checking the sta pointer before retrieving the mvmsta<br /> from it. If sta is not NULL, then mvmsta isn&amp;#39;t either.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix array out-of-bound access in SoC stats<br /> <br /> Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a<br /> maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()<br /> function access ath11k_soc_dp_stats::hal_reo_error using the REO<br /> destination SRNG ring ID, which is incorrect. SRNG ring ID differ from<br /> normal ring ID, and this usage leads to out-of-bounds array access. To fix<br /> this issue, modify ath11k_dp_process_rx() to use the normal ring ID<br /> directly instead of the SRNG ring ID to avoid out-of-bounds array access.<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: pxafb: Fix possible use after free in pxafb_task()<br /> <br /> In the pxafb_probe function, it calls the pxafb_init_fbinfo function,<br /> after which &amp;fbi-&gt;task is associated with pxafb_task. Moreover,<br /> within this pxafb_init_fbinfo function, the pxafb_blank function<br /> within the &amp;pxafb_ops struct is capable of scheduling work.<br /> <br /> If we remove the module which will call pxafb_remove to make cleanup,<br /> it will call unregister_framebuffer function which can call<br /> do_unregister_framebuffer to free fbi-&gt;fb through<br /> put_fb_info(fb_info), while the work mentioned above will be used.<br /> The sequence of operations that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | pxafb_task<br /> pxafb_remove |<br /> unregister_framebuffer(info) |<br /> do_unregister_framebuffer(fb_info) |<br /> put_fb_info(fb_info) |<br /> // free fbi-&gt;fb | set_ctrlr_state(fbi, state)<br /> | __pxafb_lcd_power(fbi, 0)<br /> | fbi-&gt;lcd_power(on, &amp;fbi-&gt;fb.var)<br /> | //use fbi-&gt;fb<br /> <br /> Fix it by ensuring that the work is canceled before proceeding<br /> with the cleanup in pxafb_remove.<br /> <br /> Note that only root user can remove the driver at runtime.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ioapic: Handle allocation failures gracefully<br /> <br /> Breno observed panics when using failslab under certain conditions during<br /> runtime:<br /> <br /> can not alloc irq_pin_list (-1,0,20)<br /> Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed<br /> <br /> panic+0x4e9/0x590<br /> mp_irqdomain_alloc+0x9ab/0xa80<br /> irq_domain_alloc_irqs_locked+0x25d/0x8d0<br /> __irq_domain_alloc_irqs+0x80/0x110<br /> mp_map_pin_to_irq+0x645/0x890<br /> acpi_register_gsi_ioapic+0xe6/0x150<br /> hpet_open+0x313/0x480<br /> <br /> That&amp;#39;s a pointless panic which is a leftover of the historic IO/APIC code<br /> which panic&amp;#39;ed during early boot when the interrupt allocation failed.<br /> <br /> The only place which might justify panic is the PIT/HPET timer_check() code<br /> which tries to figure out whether the timer interrupt is delivered through<br /> the IO/APIC. But that code does not require to handle interrupt allocation<br /> failures. If the interrupt cannot be allocated then timer delivery fails<br /> and it either panics due to that or falls back to legacy mode.<br /> <br /> Cure this by removing the panic wrapper around __add_pin_to_irq_node() and<br /> making mp_irqdomain_alloc() aware of the failure condition and handle it as<br /> any other failure in this function gracefully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check null pointer before try to access it<br /> <br /> [why &amp; how]<br /> Change the order of the pipe_ctx-&gt;plane_state check to ensure that<br /> plane_state is not null before accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null check for &amp;#39;afb&amp;#39; in amdgpu_dm_update_cursor (v2)<br /> <br /> This commit adds a null check for the &amp;#39;afb&amp;#39; variable in the<br /> amdgpu_dm_update_cursor function. Previously, &amp;#39;afb&amp;#39; was assumed to be<br /> null at line 8388, but was used later in the code without a null check.<br /> This could potentially lead to a null pointer dereference.<br /> <br /> Changes since v1:<br /> - Moved the null check for &amp;#39;afb&amp;#39; to the line where &amp;#39;afb&amp;#39; is used. (Alex)<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor()<br /> error: we previously assumed &amp;#39;afb&amp;#39; could be null (see line 8388)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func<br /> <br /> This commit adds a null check for the set_output_gamma function pointer<br /> in the dcn401_set_output_transfer_func function. Previously,<br /> set_output_gamma was being checked for null, but then it was being<br /> dereferenced without any null check. This could lead to a null pointer<br /> dereference if set_output_gamma is null.<br /> <br /> To fix this, we now ensure that set_output_gamma is not null before<br /> dereferencing it. We do this by adding a null check for set_output_gamma<br /> before the call to set_output_gamma.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe<br /> <br /> This commit addresses a null pointer dereference issue in the<br /> `dcn20_program_pipe` function. The issue could occur when<br /> `pipe_ctx-&gt;plane_state` is null.<br /> <br /> The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null<br /> before accessing. This prevents a null pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed &amp;#39;pipe_ctx-&gt;plane_state&amp;#39; could be null (see line 1877)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn401_init_hw<br /> <br /> This commit addresses a potential null pointer dereference issue in the<br /> `dcn401_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or<br /> `dc-&gt;clk_mgr-&gt;funcs` is null.<br /> <br /> The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is<br /> not null before accessing its functions. This prevents a potential null<br /> pointer dereference.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed &amp;#39;dc-&gt;clk_mgr&amp;#39; could be null (see line 225)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func<br /> <br /> This commit adds a null check for the set_output_gamma function pointer<br /> in the dcn32_set_output_transfer_func function. Previously,<br /> set_output_gamma was being checked for null, but then it was being<br /> dereferenced without any null check. This could lead to a null pointer<br /> dereference if set_output_gamma is null.<br /> <br /> To fix this, we now ensure that set_output_gamma is not null before<br /> dereferencing it. We do this by adding a null check for set_output_gamma<br /> before the call to set_output_gamma.