Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix netdev refcount issue<br /> <br /> The dev_tracker is added to ax25_cb in ax25_bind(). When the<br /> ax25 device is detaching, the dev_tracker of ax25_cb should be<br /> deallocated in ax25_kill_by_device() instead of the dev_tracker<br /> of ax25_dev. The log reported by ref_tracker is shown below:<br /> <br /> [ 80.884935] ref_tracker: reference already released.<br /> [ 80.885150] ref_tracker: allocated in:<br /> [ 80.885349] ax25_dev_device_up+0x105/0x540<br /> [ 80.885730] ax25_device_event+0xa4/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] __dev_notify_flags+0x138/0x280<br /> [ 80.885730] dev_change_flags+0xd7/0x180<br /> [ 80.885730] dev_ifsioc+0x6a9/0xa30<br /> [ 80.885730] dev_ioctl+0x4d8/0xd90<br /> [ 80.885730] sock_do_ioctl+0x1c2/0x2d0<br /> [ 80.885730] sock_ioctl+0x38b/0x4f0<br /> [ 80.885730] __se_sys_ioctl+0xad/0xf0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.885730] ref_tracker: freed in:<br /> [ 80.885730] ax25_device_event+0x272/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] dev_close_many+0x272/0x370<br /> [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180<br /> [ 80.885730] unregister_netdev+0xcf/0x120<br /> [ 80.885730] sixpack_close+0x11f/0x1b0<br /> [ 80.885730] tty_ldisc_kill+0xcb/0x190<br /> [ 80.885730] tty_ldisc_hangup+0x338/0x3d0<br /> [ 80.885730] __tty_hangup+0x504/0x740<br /> [ 80.885730] tty_release+0x46e/0xd80<br /> [ 80.885730] __fput+0x37f/0x770<br /> [ 80.885730] __x64_sys_close+0x7b/0xb0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.893739] ------------[ cut here ]------------<br /> [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0<br /> [ 80.894297] Modules linked in:<br /> [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11<br /> [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4<br /> [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0<br /> [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9<br /> [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286<br /> [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000<br /> [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518<br /> [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a<br /> [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4<br /> [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518<br /> [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000<br /> [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0<br /> ...<br /> [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at<br /> [ 80.935774] ax25_bind+0x424/0x4e0<br /> [ 80.935774] __sys_bind+0x1d9/0x270<br /> [ 80.935774] __x64_sys_bind+0x75/0x80<br /> [ 80.935774] do_syscall_64+0xc4/0x1b0<br /> [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> <br /> Change ax25_dev-&gt;dev_tracker to the dev_tracker of ax25_cb<br /> in order to mitigate the bug.

A vulnerability classified as problematic was found in PHPGurukul Directory Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/admin-profile.php of the component Searchbar. The manipulation leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-265213 was assigned to this vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix warning during rehash<br /> <br /> As previously explained, the rehash delayed work migrates filters from<br /> one region to another. This is done by iterating over all chunks (all<br /> the filters with the same priority) in the region and in each chunk<br /> iterating over all the filters.<br /> <br /> When the work runs out of credits it stores the current chunk and entry<br /> as markers in the per-work context so that it would know where to resume<br /> the migration from the next time the work is scheduled.<br /> <br /> Upon error, the chunk marker is reset to NULL, but without resetting the<br /> entry markers despite being relative to it. This can result in migration<br /> being resumed from an entry that does not belong to the chunk being<br /> migrated. In turn, this will eventually lead to a chunk being iterated<br /> over as if it is an entry. Because of how the two structures happen to<br /> be defined, this does not lead to KASAN splats, but to warnings such as<br /> [1].<br /> <br /> Fix by creating a helper that resets all the markers and call it from<br /> all the places the currently only reset the chunk marker. For good<br /> measures also call it when starting a completely new rehash. Add a<br /> warning to avoid future cases.<br /> <br /> [1]<br /> WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0<br /> Modules linked in:<br /> CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:mlxsw_afk_encode+0x242/0x2f0<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0<br /> mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix incorrect list API usage<br /> <br /> Both the function that migrates all the chunks within a region and the<br /> function that migrates all the entries within a chunk call<br /> list_first_entry() on the respective lists without checking that the<br /> lists are not empty. This is incorrect usage of the API, which leads to<br /> the following warning [1].<br /> <br /> Fix by returning if the lists are empty as there is nothing to migrate<br /> in this case.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0&gt;<br /> Modules linked in:<br /> CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: honor table dormant flag from netdev release event path<br /> <br /> Check for table dormant flag otherwise netdev release event path tries<br /> to unregister an already unregistered hook.<br /> <br /> [524854.857999] ------------[ cut here ]------------<br /> [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260<br /> [...]<br /> [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365<br /> [524854.858869] Workqueue: netns cleanup_net<br /> [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260<br /> [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41<br /> [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246<br /> [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a<br /> [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438<br /> [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34<br /> [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005<br /> [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00<br /> [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000<br /> [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0<br /> [524854.859000] Call Trace:<br /> [524854.859006] <br /> [524854.859013] ? __warn+0x9f/0x1a0<br /> [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260<br /> [524854.859044] ? report_bug+0x1b1/0x1e0<br /> [524854.859060] ? handle_bug+0x3c/0x70<br /> [524854.859071] ? exc_invalid_op+0x17/0x40<br /> [524854.859083] ? asm_exc_invalid_op+0x1a/0x20<br /> [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260<br /> [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260<br /> [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables]<br /> [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]<br /> [524854.859461] ? packet_notifier+0xb3/0x360<br /> [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> [524854.859489] ? dcbnl_netdevice_event+0x35/0x140<br /> [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]<br /> [524854.859661] notifier_call_chain+0x7d/0x140<br /> [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Do not use WQ_MEM_RECLAIM flag for workqueue<br /> <br /> Issue reported by customer during SRIOV testing, call trace:<br /> When both i40e and the i40iw driver are loaded, a warning<br /> in check_flush_dependency is being triggered. This seems<br /> to be because of the i40e driver workqueue is allocated with<br /> the WQ_MEM_RECLAIM flag, and the i40iw one is not.<br /> <br /> Similar error was encountered on ice too and it was fixed by<br /> removing the flag. Do the same for i40e too.<br /> <br /> [Feb 9 09:08] ------------[ cut here ]------------<br /> [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is<br /> flushing !WQ_MEM_RECLAIM infiniband:0x0<br /> [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966<br /> check_flush_dependency+0x10b/0x120<br /> [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq<br /> snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4<br /> nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr<br /> rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma<br /> intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif<br /> isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal<br /> intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core<br /> iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore<br /> ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich<br /> intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad<br /> xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe<br /> drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel<br /> libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror<br /> dm_region_hash dm_log dm_mod fuse<br /> [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not<br /> tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1<br /> [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS<br /> SE5C620.86B.02.01.0013.121520200651 12/15/2020<br /> [ +0.000001] Workqueue: i40e i40e_service_task [i40e]<br /> [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120<br /> [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48<br /> 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd<br /> ff 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90<br /> [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282<br /> [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:<br /> 0000000000000027<br /> [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:<br /> ffff94d47f620bc0<br /> [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:<br /> 00000000ffff7fff<br /> [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:<br /> ffff94c5451ea180<br /> [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:<br /> ffff94c5f1330ab0<br /> [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)<br /> knlGS:0000000000000000<br /> [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:<br /> 00000000007706f0<br /> [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ +0.000001] PKRU: 55555554<br /> [ +0.000001] Call Trace:<br /> [ +0.000001] <br /> [ +0.000002] ? __warn+0x80/0x130<br /> [ +0.000003] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? report_bug+0x195/0x1a0<br /> [ +0.000005] ? handle_bug+0x3c/0x70<br /> [ +0.000003] ? exc_invalid_op+0x14/0x70<br /> [ +0.000002] ? asm_exc_invalid_op+0x16/0x20<br /> [ +0.000006] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] __flush_workqueue+0x126/0x3f0<br /> [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]<br /> [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]<br /> [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]<br /> [ +0.000020] i40iw_close+0x4b/0x90 [irdma]<br /> [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]<br /> [ +0.000035] i40e_service_task+0x126/0x190 [i40e]<br /> [ +0.000024] process_one_work+0x174/0x340<br /> [ +0.000003] worker_th<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix loading 64-bit NOMMU kernels past the start of RAM<br /> <br /> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear<br /> mapping") added logic to allow using RAM below the kernel load address.<br /> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the<br /> kernel load address. Since that range of memory corresponds to PFNs<br /> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of<br /> mem_map and corrupts adjacent kernel memory. Fix this by restoring the<br /> previous behavior for NOMMU kernels.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix oops during rmmod on single-CPU platforms<br /> <br /> During the removal of the idxd driver, registered offline callback is<br /> invoked as part of the clean up process. However, on systems with only<br /> one CPU online, no valid target is available to migrate the<br /> perf context, resulting in a kernel oops:<br /> <br /> BUG: unable to handle page fault for address: 000000000002a2b8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 1470e1067 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57<br /> Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023<br /> RIP: 0010:mutex_lock+0x2e/0x50<br /> ...<br /> Call Trace:<br /> <br /> __die+0x24/0x70<br /> page_fault_oops+0x82/0x160<br /> do_user_addr_fault+0x65/0x6b0<br /> __pfx___rdmsr_safe_on_cpu+0x10/0x10<br /> exc_page_fault+0x7d/0x170<br /> asm_exc_page_fault+0x26/0x30<br /> mutex_lock+0x2e/0x50<br /> mutex_lock+0x1e/0x50<br /> perf_pmu_migrate_context+0x87/0x1f0<br /> perf_event_cpu_offline+0x76/0x90 [idxd]<br /> cpuhp_invoke_callback+0xa2/0x4f0<br /> __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]<br /> cpuhp_thread_fun+0x98/0x150<br /> smpboot_thread_fn+0x27/0x260<br /> smpboot_thread_fn+0x1af/0x260<br /> __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0x103/0x140<br /> __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Fix the issue by preventing the migration of the perf context to an<br /> invalid target.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma: xilinx_dpdma: Fix locking<br /> <br /> There are several places where either chan-&gt;lock or chan-&gt;vchan.lock was<br /> not held. Add appropriate locking. This fixes lockdep warnings like<br /> <br /> [ 31.077578] ------------[ cut here ]------------<br /> [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.077953] Modules linked in:<br /> [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98<br /> [ 31.078102] Hardware name: xlnx,zynqmp (DT)<br /> [ 31.078169] Workqueue: events_unbound deferred_probe_work_func<br /> [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0<br /> [ 31.078550] sp : ffffffc083bb2e10<br /> [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168<br /> [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480<br /> [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000<br /> [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000<br /> [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001<br /> [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def<br /> [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516<br /> [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff<br /> [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000<br /> [ 31.080307] Call trace:<br /> [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0<br /> [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120<br /> [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac<br /> [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c<br /> [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684<br /> [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0<br /> [ 31.081139] commit_tail+0x234/0x294<br /> [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210<br /> [ 31.081363] drm_atomic_commit+0x100/0x140<br /> [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384<br /> [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c<br /> [ 31.081725] drm_client_modeset_commit+0x34/0x5c<br /> [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168<br /> [ 31.081899] drm_fb_helper_set_par+0x50/0x70<br /> [ 31.081971] fbcon_init+0x538/0xc48<br /> [ 31.082047] visual_init+0x16c/0x23c<br /> [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634<br /> [ 31.082320] do_take_over_console+0x24c/0x33c<br /> [ 31.082429] do_fbcon_takeover+0xbc/0x1b0<br /> [ 31.082503] fbcon_fb_registered+0x2d0/0x34c<br /> [ 31.082663] register_framebuffer+0x27c/0x38c<br /> [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c<br /> [ 31.082939] drm_fb_helper_initial_config+0x50/0x74<br /> [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108<br /> [ 31.083115] drm_client_register+0xa0/0xf4<br /> [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc<br /> [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0<br /> [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0<br /> [ 31.083616] platform_probe+0x8c/0x13c<br /> [ 31.083713] really_probe+0x258/0x59c<br /> [ 31.083793] __driver_probe_device+0xc4/0x224<br /> [ 31.083878] driver_probe_device+0x70/0x1c0<br /> [ 31.083961] __device_attach_driver+0x108/0x1e0<br /> [ 31.084052] bus_for_each_drv+0x9c/0x100<br /> [ 31.084125] __device_attach+0x100/0x298<br /> [ 31.084207] device_initial_probe+0x14/0x20<br /> [ 31.084292] bus_probe_device+0xd8/0xdc<br /> [ 31.084368] deferred_probe_work_func+0x11c/0x180<br /> [ 31.084451] process_one_work+0x3ac/0x988<br /> [ 31.084643] worker_thread+0x398/0x694<br /> [ 31.084752] kthread+0x1bc/0x1c0<br /> [ 31.084848] ret_from_fork+0x10/0x20<br /> [ 31.084932] irq event stamp: 64549<br /> [ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90<br /> [ 31.085157]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue<br /> <br /> drain_workqueue() cannot be called safely in a spinlocked context due to<br /> possible task rescheduling. In the multi-task scenario, calling<br /> queue_work() while drain_workqueue() will lead to a Call Trace as<br /> pushing a work on a draining workqueue is not permitted in spinlocked<br /> context.<br /> Call Trace:<br /> <br /> ? __warn+0x7d/0x140<br /> ? __queue_work+0x2b2/0x440<br /> ? report_bug+0x1f8/0x200<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __queue_work+0x2b2/0x440<br /> queue_work_on+0x28/0x30<br /> idxd_misc_thread+0x303/0x5a0 [idxd]<br /> ? __schedule+0x369/0xb40<br /> ? __pfx_irq_thread_fn+0x10/0x10<br /> ? irq_thread+0xbc/0x1b0<br /> irq_thread_fn+0x21/0x70<br /> irq_thread+0x102/0x1b0<br /> ? preempt_count_add+0x74/0xa0<br /> ? __pfx_irq_thread_dtor+0x10/0x10<br /> ? __pfx_irq_thread+0x10/0x10<br /> kthread+0x103/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The current implementation uses a spinlock to protect event log workqueue<br /> and will lead to the Call Trace due to potential task rescheduling.<br /> <br /> To address the locking issue, convert the spinlock to mutex, allowing<br /> the drain_workqueue() to be called in a safe mutex-locked context.<br /> <br /> This change ensures proper synchronization when accessing the event log<br /> workqueue, preventing potential Call Trace and improving the overall<br /> robustness of the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: marvell: a3700-comphy: Fix out of bounds read<br /> <br /> There is an out of bounds read access of &amp;#39;gbe_phy_init_fix[fix_idx].addr&amp;#39;<br /> every iteration after &amp;#39;fix_idx&amp;#39; reaches &amp;#39;ARRAY_SIZE(gbe_phy_init_fix)&amp;#39;.<br /> <br /> Make sure &amp;#39;gbe_phy_init[addr]&amp;#39; is used when all elements of<br /> &amp;#39;gbe_phy_init_fix&amp;#39; array are handled.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: turn folio_test_hugetlb into a PageType<br /> <br /> The current folio_test_hugetlb() can be fooled by a concurrent folio split<br /> into returning true for a folio which has never belonged to hugetlbfs. <br /> This can&amp;#39;t happen if the caller holds a refcount on it, but we have a few<br /> places (memory-failure, compaction, procfs) which do not and should not<br /> take a speculative reference.<br /> <br /> Since hugetlb pages do not use individual page mapcounts (they are always<br /> fully mapped and use the entire_mapcount field to record the number of<br /> mappings), the PageType field is available now that page_mapcount()<br /> ignores the value in this field.<br /> <br /> In compaction and with CONFIG_DEBUG_VM enabled, the current implementation<br /> can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b<br /> ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks<br /> in the PageHuge() testing path.<br /> <br /> [willy@infradead.org: update vmcoreinfo]