CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50031 – drm/v3d: Stop the active perfmon before being destroyed
https://notcve.org/view.php?id=CVE-2024-50031
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. • https://git.kernel.org/stable/c/26a4dc29b74a137f45665089f6d3d633fcc9b662 https://git.kernel.org/stable/c/24ab54a066d2ef671b03eb909ca2114c0c9ac1e7 https://git.kernel.org/stable/c/0c9e9a3a4873705740b19300cadc6599170646ef https://git.kernel.org/stable/c/07c51108d9e278831c16191d1223ee49986e7890 https://git.kernel.org/stable/c/333767cbce6ac20ec794c76eec82ed0ef55022db https://git.kernel.org/stable/c/7d1fd3638ee3a9f9bca4785fffb638ca19120718 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50028 – thermal: core: Reference count the zone in thermal_zone_get_by_id()
https://notcve.org/view.php?id=CVE-2024-50028
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. • https://git.kernel.org/stable/c/1ce50e7d408ef2bdc8ca021363fd46d1b8bfad00 https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802 https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50026 – scsi: wd33c93: Don't use stale scsi_pointer value
https://notcve.org/view.php?id=CVE-2024-50026
In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting. • https://git.kernel.org/stable/c/dbb2da557a6a87c88bbb4b1fef037091b57f701b https://git.kernel.org/stable/c/3afeceda855dea9b85cddd96307d4d17c8742005 https://git.kernel.org/stable/c/e04642a207f1d2ae28a08624c04c67f5681f3451 https://git.kernel.org/stable/c/b60ff1a95c7c386cdd6153de3d7d85edaeabd800 https://git.kernel.org/stable/c/9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50024 – net: Fix an unsafe loop on the list
https://notcve.org/view.php?id=CVE-2024-50024
In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. • https://git.kernel.org/stable/c/b8273570f802a7658827dcb077b0b517ba75a289 https://git.kernel.org/stable/c/464801a0f6ccb52b21faa33bac6014fd74cc5e10 https://git.kernel.org/stable/c/8e0766fcf37ad8eed289dd3853628dd9b01b58b0 https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013 https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0 https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50022 – device-dax: correct pgoff align in dax_set_mapping()
https://notcve.org/view.php?id=CVE-2024-50022
In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). • https://git.kernel.org/stable/c/b9b5777f09be84d0de472ded2253d2f5101427f2 https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86 https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6 https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6 •