Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kunit: string-stream: Fix a UAF bug in kunit_init_suite()<br /> <br /> In kunit_debugfs_create_suite(), if alloc_string_stream() fails in the<br /> kunit_suite_for_each_test_case() loop, the "suite-&gt;log = stream"<br /> has assigned before, and the error path only free the suite-&gt;log&amp;#39;s stream<br /> memory but not set it to NULL, so the later string_stream_clear() of<br /> suite-&gt;log in kunit_init_suite() will cause below UAF bug.<br /> <br /> Set stream pointer to NULL after free to fix it.<br /> <br /> Unable to handle kernel paging request at virtual address 006440150000030d<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [006440150000030d] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in: iio_test_gts industrialio_gts_helper cfg80211 rfkill ipv6 [last unloaded: iio_test_gts]<br /> CPU: 5 UID: 0 PID: 6253 Comm: modprobe Tainted: G B W N 6.12.0-rc4+ #458<br /> Tainted: [B]=BAD_PAGE, [W]=WARN, [N]=TEST<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : string_stream_clear+0x54/0x1ac<br /> lr : string_stream_clear+0x1a8/0x1ac<br /> sp : ffffffc080b47410<br /> x29: ffffffc080b47410 x28: 006440550000030d x27: ffffff80c96b5e98<br /> x26: ffffff80c96b5e80 x25: ffffffe461b3f6c0 x24: 0000000000000003<br /> x23: ffffff80c96b5e88 x22: 1ffffff019cdf4fc x21: dfffffc000000000<br /> x20: ffffff80ce6fa7e0 x19: 032202a80000186d x18: 0000000000001840<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffffe45c355cb4<br /> x14: ffffffe45c35589c x13: ffffffe45c03da78 x12: ffffffb810168e75<br /> x11: 1ffffff810168e74 x10: ffffffb810168e74 x9 : dfffffc000000000<br /> x8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001<br /> x5 : ffffffc080b473a0 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000001 x1 : ffffffe462fbf620 x0 : dfffffc000000000<br /> Call trace:<br /> string_stream_clear+0x54/0x1ac<br /> __kunit_test_suites_init+0x108/0x1d8<br /> kunit_exec_run_tests+0xb8/0x100<br /> kunit_module_notify+0x400/0x55c<br /> notifier_call_chain+0xfc/0x3b4<br /> blocking_notifier_call_chain+0x68/0x9c<br /> do_init_module+0x24c/0x5c8<br /> load_module+0x4acc/0x4e90<br /> init_module_from_file+0xd4/0x128<br /> idempotent_init_module+0x2d4/0x57c<br /> __arm64_sys_finit_module+0xac/0x100<br /> invoke_syscall+0x6c/0x258<br /> el0_svc_common.constprop.0+0x160/0x22c<br /> do_el0_svc+0x44/0x5c<br /> el0_svc+0x48/0xb8<br /> el0t_64_sync_handler+0x13c/0x158<br /> el0t_64_sync+0x190/0x194<br /> Code: f9400753 d2dff800 f2fbffe0 d343fe7c (38e06b80)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

Command Injection in Minidlna version v1.3.3 and before allows an attacker to execute arbitrary OS commands via a specially crafted minidlna.conf configuration file.

In DevmemIntMapPages of devicemem_server.c, there is a possible physical page uaf due to a logic error in the code. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.