Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()<br /> <br /> It is possible that typec_register_partner() returns ERR_PTR on failure.<br /> When port-&gt;partner is an error, a NULL pointer dereference may occur as<br /> shown below.<br /> <br /> [91222.095236][ T319] typec port0: failed to register partner (-17)<br /> ...<br /> [91225.061491][ T319] Unable to handle kernel NULL pointer dereference<br /> at virtual address 000000000000039f<br /> [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc<br /> [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc<br /> [91225.308067][ T319] Call trace:<br /> [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc<br /> [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8<br /> [91225.355900][ T319] kthread_worker_fn+0x178/0x58c<br /> [91225.355902][ T319] kthread+0x150/0x200<br /> [91225.355905][ T319] ret_from_fork+0x10/0x30<br /> <br /> Add a check for port-&gt;partner to avoid dereferencing a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: can_put_echo_skb(): don&amp;#39;t crash kernel if can_priv::echo_skb is accessed out of bounds<br /> <br /> If the "struct can_priv::echoo_skb" is accessed out of bounds, this<br /> would cause a kernel crash. Instead, issue a meaningful warning<br /> message and return with an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Have trace_event_file have ref counters<br /> <br /> The following can crash the kernel:<br /> <br /> # cd /sys/kernel/tracing<br /> # echo &amp;#39;p:sched schedule&amp;#39; &gt; kprobe_events<br /> # exec 5&gt;&gt;events/kprobes/sched/enable<br /> # &gt; kprobe_events<br /> # exec 5&gt;&amp;-<br /> <br /> The above commands:<br /> <br /> 1. Change directory to the tracefs directory<br /> 2. Create a kprobe event (doesn&amp;#39;t matter what one)<br /> 3. Open bash file descriptor 5 on the enable file of the kprobe event<br /> 4. Delete the kprobe event (removes the files too)<br /> 5. Close the bash file descriptor 5<br /> <br /> The above causes a crash!<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:tracing_release_file_tr+0xc/0x50<br /> <br /> What happens here is that the kprobe event creates a trace_event_file<br /> "file" descriptor that represents the file in tracefs to the event. It<br /> maintains state of the event (is it enabled for the given instance?).<br /> Opening the "enable" file gets a reference to the event "file" descriptor<br /> via the open file descriptor. When the kprobe event is deleted, the file is<br /> also deleted from the tracefs system which also frees the event "file"<br /> descriptor.<br /> <br /> But as the tracefs file is still opened by user space, it will not be<br /> totally removed until the final dput() is called on it. But this is not<br /> true with the event "file" descriptor that is already freed. If the user<br /> does a write to or simply closes the file descriptor it will reference the<br /> event "file" descriptor that was just freed, causing a use-after-free bug.<br /> <br /> To solve this, add a ref count to the event "file" descriptor as well as a<br /> new flag called "FREED". The "file" will not be freed until the last<br /> reference is released. But the FREE flag will be set when the event is<br /> removed to prevent any more modifications to that event from happening,<br /> even if there&amp;#39;s still a reference to the event "file" descriptor.

Improper Verification of Cryptographic Signature vulnerability in HYPR Passwordless on Windows allows Malicious Software Update.This issue affects HYPR Passwordless: before 9.1.

An incorrect permission assignment for critical resource vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow authenticated users to read or modify the resource via a network.<br /> <br /> We have already fixed the vulnerability in the following version:<br /> QTS 5.1.7.2770 build 20240520 and later<br /> QuTS hero h5.1.7.2770 build 20240520 and later

A double free vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow authenticated users to execute arbitrary code via a network.<br /> <br /> We have already fixed the vulnerability in the following version:<br /> QTS 5.1.7.2770 build 20240520 and later<br /> QuTS hero h5.1.7.2770 build 20240520 and later

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process<br /> <br /> When tearing down a &amp;#39;hisi_hns3&amp;#39; PMU, we mistakenly run the CPU hotplug<br /> callbacks after the device has been unregistered, leading to fireworks<br /> when we try to execute empty function callbacks within the driver:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1<br /> | Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021<br /> | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)<br /> | pc : perf_pmu_migrate_context+0x98/0x38c<br /> | lr : perf_pmu_migrate_context+0x94/0x38c<br /> |<br /> | Call trace:<br /> | perf_pmu_migrate_context+0x98/0x38c<br /> | hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]<br /> <br /> Use cpuhp_state_remove_instance_nocalls() instead of<br /> cpuhp_state_remove_instance() so that the notifiers don&amp;#39;t execute after<br /> the PMU device has been unregistered.<br /> <br /> [will: Rewrote commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: it66121: Fix invalid connector dereference<br /> <br /> Fix the NULL pointer dereference when no monitor is connected, and the<br /> sound card is opened from userspace.<br /> <br /> Instead return an empty buffer (of zeroes) as the EDID information to<br /> the sound framework if there is no connector attached.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null pointer dereference in error message<br /> <br /> This patch fixes a null pointer dereference in the error message that is<br /> printed when the Display Core (DC) fails to initialize. The original<br /> message includes the DC version number, which is undefined if the DC is<br /> not initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (axi-fan-control) Fix possible NULL pointer dereference<br /> <br /> axi_fan_control_irq_handler(), dependent on the private<br /> axi_fan_control_data structure, might be called before the hwmon<br /> device is registered. That will cause an "Unable to handle kernel<br /> NULL pointer dereference" error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: wmi: Fix opening of char device<br /> <br /> Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via<br /> file private data"), the miscdevice stores a pointer to itself inside<br /> filp-&gt;private_data, which means that private_data will not be NULL when<br /> wmi_char_open() is called. This might cause memory corruption should<br /> wmi_char_open() be unable to find its driver, something which can<br /> happen when the associated WMI device is deleted in wmi_free_devices().<br /> <br /> Fix the problem by using the miscdevice pointer to retrieve the WMI<br /> device data associated with a char device using container_of(). This<br /> also avoids wmi_char_open() picking a wrong WMI device bound to a<br /> driver with the same name as the original driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data<br /> <br /> Add the check for the return value of mtk_alloc_clk_data() in order to<br /> avoid NULL pointer dereference.