Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a<br /> <br /> Fix the dtc warnings:<br /> <br /> arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &amp;#39;#interrupt-cells&amp;#39; found, but node is not an interrupt provider<br /> arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &amp;#39;#interrupt-cells&amp;#39; found, but node is not an interrupt provider<br /> arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite &amp;#39;interrupt_provider&amp;#39;<br /> <br /> And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on<br /> deprecated #address-cells/#size-cells handling"):<br /> <br /> WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0<br /> Missing &amp;#39;#address-cells&amp;#39; in /bus@10000000/pci@1a000000/pci_bridge@9,0<br /> <br /> The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe<br /> port nodes for ls7a"), which has fixed the issue for ls2k (despite its<br /> subject mentions ls7a).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: imx8m: Probe the SoC driver as platform driver<br /> <br /> With driver_async_probe=* on kernel command line, the following trace is<br /> produced because on i.MX8M Plus hardware because the soc-imx8m.c driver<br /> calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock<br /> driver is not yet probed. This was not detected during regular testing<br /> without driver_async_probe.<br /> <br /> Convert the SoC code to platform driver and instantiate a platform device<br /> in its current device_initcall() to probe the platform driver. Rework<br /> .soc_revision callback to always return valid error code and return SoC<br /> revision via parameter. This way, if anything in the .soc_revision callback<br /> return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get<br /> retried later.<br /> <br /> "<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180<br /> CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603<br /> Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : imx8mm_soc_revision+0xdc/0x180<br /> lr : imx8mm_soc_revision+0xd0/0x180<br /> sp : ffff8000821fbcc0<br /> x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120<br /> x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311<br /> x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb<br /> x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff<br /> x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8<br /> x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801<br /> x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c<br /> x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3<br /> x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb<br /> Call trace:<br /> imx8mm_soc_revision+0xdc/0x180<br /> imx8_soc_init+0xb0/0x1e0<br /> do_one_initcall+0x94/0x1a8<br /> kernel_init_freeable+0x240/0x2a8<br /> kernel_init+0x28/0x140<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> SoC: i.MX8MP revision 1.1<br /> "

A malformed 802.15.4 packet causes a buffer overflow to occur leading to an assert and a denial of service. A watchdog reset clears the error condition automatically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix handling of plane refcount<br /> <br /> [Why]<br /> The mechanism to backup and restore plane states doesn&amp;#39;t maintain<br /> refcount, which can cause issues if the refcount of the plane changes<br /> in between backup and restore operations, such as memory leaks if the<br /> refcount was supposed to go down, or double frees / invalid memory<br /> accesses if the refcount was supposed to go up.<br /> <br /> [How]<br /> Cache and re-apply current refcount when restoring plane states.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kunit: Fix potential null dereference in kunit_device_driver_test()<br /> <br /> kunit_kzalloc() may return a NULL pointer, dereferencing it without<br /> NULL check may lead to NULL dereference.<br /> Add a NULL check for test_state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add a sanity check for btrfs root in btrfs_search_slot()<br /> <br /> Syzbot reports a null-ptr-deref in btrfs_search_slot().<br /> <br /> The reproducer is using rescue=ibadroots, and the extent tree root is<br /> corrupted thus the extent tree is NULL.<br /> <br /> When scrub tries to search the extent tree to gather the needed extent<br /> info, btrfs_search_slot() doesn&amp;#39;t check if the target root is NULL or<br /> not, resulting the null-ptr-deref.<br /> <br /> Add sanity check for btrfs root before using it in btrfs_search_slot().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sti: avoid potential dereference of error pointers<br /> <br /> The return value of drm_atomic_get_crtc_state() needs to be<br /> checked. To avoid use of error pointer &amp;#39;crtc_state&amp;#39; in case<br /> of the failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check<br /> <br /> The return value of drm_atomic_get_crtc_state() needs to be<br /> checked. To avoid use of error pointer &amp;#39;crtc_state&amp;#39; in case<br /> of the failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check<br /> <br /> The return value of drm_atomic_get_crtc_state() needs to be<br /> checked. To avoid use of error pointer &amp;#39;crtc_state&amp;#39; in case<br /> of the failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur<br /> <br /> The action force umount(umount -f) will attempt to kill all rpc_task even<br /> umount operation may ultimately fail if some files remain open.<br /> Consequently, if an action attempts to open a file, it can potentially<br /> send two rpc_task to nfs server.<br /> <br /> NFS CLIENT<br /> thread1 thread2<br /> open("file")<br /> ...<br /> nfs4_do_open<br /> _nfs4_do_open<br /> _nfs4_open_and_get_state<br /> _nfs4_proc_open<br /> nfs4_run_open_task<br /> /* rpc_task1 */<br /> rpc_run_task<br /> rpc_wait_for_completion_task<br /> <br /> umount -f<br /> nfs_umount_begin<br /> rpc_killall_tasks<br /> rpc_signal_task<br /> rpc_task1 been wakeup<br /> and return -512<br /> _nfs4_do_open // while loop<br /> ...<br /> nfs4_run_open_task<br /> /* rpc_task2 */<br /> rpc_run_task<br /> rpc_wait_for_completion_task<br /> <br /> While processing an open request, nfsd will first attempt to find or<br /> allocate an nfs4_openowner. If it finds an nfs4_openowner that is not<br /> marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since<br /> two rpc_task can attempt to open the same file simultaneously from the<br /> client to server, and because two instances of nfsd can run<br /> concurrently, this situation can lead to lots of memory leak.<br /> Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be<br /> triggered.<br /> <br /> NFS SERVER<br /> nfsd1 nfsd2 echo 0 &gt; /proc/fs/nfsd/threads<br /> <br /> nfsd4_open<br /> nfsd4_process_open1<br /> find_or_alloc_open_stateowner<br /> // alloc oo1, stateid1<br /> nfsd4_open<br /> nfsd4_process_open1<br /> find_or_alloc_open_stateowner<br /> // find oo1, without NFS4_OO_CONFIRMED<br /> release_openowner<br /> unhash_openowner_locked<br /> list_del_init(&amp;oo-&gt;oo_perclient)<br /> // cannot find this oo<br /> // from client, LEAK!!!<br /> alloc_stateowner // alloc oo2<br /> <br /> nfsd4_process_open2<br /> init_open_stateid<br /> // associate oo1<br /> // with stateid1, stateid1 LEAK!!!<br /> nfs4_get_vfs_file<br /> // alloc nfsd_file1 and nfsd_file_mark1<br /> // all LEAK!!!<br /> <br /> nfsd4_process_open2<br /> ...<br /> <br /> write_threads<br /> ...<br /> nfsd_destroy_serv<br /> nfsd_shutdown_net<br /> nfs4_state_shutdown_net<br /> nfs4_state_destroy_net<br /> destroy_client<br /> __destroy_client<br /> // won&amp;#39;t find oo1!!!<br /> nfsd_shutdown_generic<br /> nfsd_file_cache_shutdown<br /> kmem_cache_destroy<br /> for nfsd_file_slab<br /> and nfsd_file_mark_slab<br /> // bark since nfsd_file1<br /> // and nfsd_file_mark1<br /> // still alive<br /> <br /> =======================================================================<br /> BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on<br /> __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------<br /> <br /> Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28<br /> flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> Call Trace:<br /> <br /> dum<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: flush quota_release_work upon quota writeback<br /> <br /> One of the paths quota writeback is called from is:<br /> <br /> freeze_super()<br /> sync_filesystem()<br /> ext4_sync_fs()<br /> dquot_writeback_dquots()<br /> <br /> Since we currently don&amp;#39;t always flush the quota_release_work queue in<br /> this path, we can end up with the following race:<br /> <br /> 1. dquot are added to releasing_dquots list during regular operations.<br /> 2. FS Freeze starts, however, this does not flush the quota_release_work queue.<br /> 3. Freeze completes.<br /> 4. Kernel eventually tries to flush the workqueue while FS is frozen which<br /> hits a WARN_ON since transaction gets started during frozen state:<br /> <br /> ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)<br /> __ext4_journal_start_sb+0x64/0x1c0 [ext4]<br /> ext4_release_dquot+0x90/0x1d0 [ext4]<br /> quota_release_workfn+0x43c/0x4d0<br /> <br /> Which is the following line:<br /> <br /> WARN_ON(sb-&gt;s_writers.frozen == SB_FREEZE_COMPLETE);<br /> <br /> Which ultimately results in generic/390 failing due to dmesg<br /> noise. This was detected on powerpc machine 15 cores.<br /> <br /> To avoid this, make sure to flush the workqueue during<br /> dquot_writeback_dquots() so we dont have any pending workitems after<br /> freeze.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information<br /> <br /> These four chips:<br /> * W25N512GW<br /> * W25N01GW<br /> * W25N01JW<br /> * W25N02JW<br /> all require a single bit of ECC strength and thus feature an on-die<br /> Hamming-like ECC engine. There is no point in filling a -&gt;get_status()<br /> callback for them because the main ECC status bytes are located in<br /> standard places, and retrieving the number of bitflips in case of<br /> corrected chunk is both useless and unsupported (if there are bitflips,<br /> then there is 1 at most, so no need to query the chip for that).<br /> <br /> Without this change, a kernel warning triggers every time a bit flips.