Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Fix refcount leak in some error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address<br /> <br /> of_get_next_parent() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() in the error path to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak when using fscache<br /> <br /> If we hit the &amp;#39;index == next_cached&amp;#39; case, we leak a refcount on the<br /> struct page. Fix this by using readahead_folio() which takes care of<br /> the refcount for you.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: max77620: Fix refcount leak in max77620_initialise_fps<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: amba-clcd: Fix refcount leak bugs<br /> <br /> In clcdfb_of_init_display(), we should call of_node_put() for the<br /> references returned by of_graph_get_next_endpoint() and<br /> of_graph_get_remote_port_parent() which have increased the refcount.<br /> <br /> Besides, we should call of_node_put() both in fail path or when<br /> the references are not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource<br /> <br /> Unlike release_mem_region(), a call to release_resource() does not<br /> free the resource, so it has to be freed explicitly to avoid a memory<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mt6359: Fix refcount leak bug<br /> <br /> In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call<br /> of_node_put() for the reference returned by of_get_child_by_name()<br /> which has increased the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoc: audio-graph-card2: Fix refcount leak bug in __graph_get_type()<br /> <br /> We should call of_node_put() for the reference before its replacement<br /> as it returned by of_get_parent() which has increased the refcount.<br /> Besides, we should also call of_node_put() before return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts<br /> <br /> Ensure SRB is returned during I/O timeout error escalation. If that is not<br /> possible fail the escalation path.<br /> <br /> Following crash stack was seen:<br /> <br /> BUG: unable to handle kernel paging request at 0000002f56aa90f8<br /> IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]<br /> Call Trace:<br /> ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]<br /> ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]<br /> ? dma_pool_alloc+0x1d6/0x210<br /> ? mempool_alloc+0x54/0x130<br /> ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]<br /> ? qla_do_work+0x2d/0x40 [qla2xxx]<br /> ? process_one_work+0x14c/0x390

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: arkfb: Check the size of screen before memset_io()<br /> <br /> In the function arkfb_set_par(), the value of &amp;#39;screen_size&amp;#39; is<br /> calculated by the user input. If the user provides the improper value,<br /> the value of &amp;#39;screen_size&amp;#39; may larger than &amp;#39;info-&gt;screen_size&amp;#39;, which<br /> may cause the following bug:<br /> <br /> [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000<br /> [ 659.399077] #PF: supervisor write access in kernel mode<br /> [ 659.399079] #PF: error_code(0x0002) - not-present page<br /> [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0<br /> [ 659.399116] Call Trace:<br /> [ 659.399122] arkfb_set_par+0x143f/0x24c0<br /> [ 659.399130] fb_set_var+0x604/0xeb0<br /> [ 659.399161] do_fb_ioctl+0x234/0x670<br /> [ 659.399189] fb_ioctl+0xdd/0x130<br /> <br /> Fix the this by checking the value of &amp;#39;screen_size&amp;#39; before memset_io().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Do not requeue task on CPU excluded from cpus_mask<br /> <br /> The following warning was triggered on a large machine early in boot on<br /> a distribution kernel but the same problem should also affect mainline.<br /> <br /> WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440<br /> Call Trace:<br /> <br /> rescuer_thread+0x1f6/0x360<br /> kthread+0x156/0x180<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p-&gt;on_cpu")<br /> optimises ttwu by queueing a task that is descheduling on the wakelist,<br /> but does not check if the task descheduling is still allowed to run on that CPU.<br /> <br /> In this warning, the problematic task is a workqueue rescue thread which<br /> checks if the rescue is for a per-cpu workqueue and running on the wrong CPU.<br /> While this is early in boot and it should be possible to create workers,<br /> the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached<br /> or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue<br /> thread is being used frequently.<br /> <br /> Tracing confirmed that the task should have migrated properly using the<br /> stopper thread to handle the migration. However, a parallel wakeup from udev<br /> running on another CPU that does not share CPU cache observes p-&gt;on_cpu and<br /> uses task_cpu(p), queues the task on the old CPU and triggers the warning.<br /> <br /> Check that the wakee task that is descheduling is still allowed to run<br /> on its current CPU and if not, wait for the descheduling to complete<br /> and select an allowed CPU.