{"id":"OESA-2025-1245","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvideo: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()\n\nI got a null-ptr-deref report:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:fb_destroy_modelist+0x38/0x100\n...\nCall Trace:\n ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]\n usb_probe_interface+0x1aa/0x3c0 [usbcore]\n really_probe+0x167/0x460\n...\n ret_from_fork+0x1f/0x30\n\nIf fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will\nbe called to destroy modelist in the error handling path. But modelist\nhas not been initialized yet, so it will result in null-ptr-deref.\n\nInitialize modelist before calling fb_alloc_cmap() to fix this bug.(CVE-2021-47652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: sata_dwc_460ex: Fix crash due to OOB write\n\nthe driver uses libata's "tag" values from in various arrays.\nSince the mentioned patch bumped the ATA_TAG_INTERNAL to 32,\nthe value of the SATA_DWC_QCMD_MAX needs to account for that.\n\nOtherwise ATA_TAG_INTERNAL usage cause similar crashes like\nthis as reported by Tice Rex on the OpenWrt Forum and\nreproduced (with symbols) here:\n\n| BUG: Kernel NULL pointer dereference at 0x00000000\n| Faulting instruction address: 0xc03ed4b8\n| Oops: Kernel access of bad area, sig: 11 [#1]\n| BE PAGE_SIZE=4K PowerPC 44x Platform\n| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0\n| NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c\n| REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)\n| MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000\n| DEAR: 00000000 ESR: 00000000\n| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]\n| [..]\n| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254\n| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc\n| Call Trace:\n| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)\n| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc\n| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524\n| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0\n| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204\n| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130\n| [...]\n\nThis is because sata_dwc_dma_xfer_complete() NULLs the\ndma_pending's next neighbour "chan" (a *dma_chan struct) in\nthis '32' case right here (line ~735):\n> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;\n\nThen the next time, a dma gets issued; dma_dwc_xfer_setup() passes\nthe NULL'd hsdevp->chan to the dmaengine_slave_config() which then\ncauses the crash.\n\nWith this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.\nThis avoids the OOB. But please note, there was a worthwhile discussion\non what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not\nbe a "fake" 33 command-long queue size.\n\nIdeally, the dw driver should account for the ATA_TAG_INTERNAL.\nIn Damien Le Moal's words: "... having looked at the driver, it\nis a bigger change than just faking a 33rd "tag" that is in fact\nnot a command tag at all."\n\nBugLink: https://github.com/openwrt/openwrt/issues/9505(CVE-2022-49073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imx: Fix memory leak in imx_pd_connector_get_modes\n\nAvoid leaking the display mode variable if of_get_drm_display_mode\nfails.\n\nAddresses-Coverity-ID: 1443943 ("Resource leak")(CVE-2022-49091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-iolatency: Fix inflight count imbalances and IO hangs on offline\n\niolatency needs to track the number of inflight IOs per cgroup. As this\ntracking can be expensive, it is disabled when no cgroup has iolatency\nconfigured for the device. To ensure that the inflight counters stay\nbalanced, iolatency_set_limit() freezes the request_queue while manipulating\nthe enabled counter, which ensures that no IO is in flight and thus all\ncounters are zero.\n\nUnfortunately, iolatency_set_limit() isn't the only place where the enabled\ncounter is manipulated. iolatency_pd_offline() can also dec the counter and\ntrigger disabling. As this disabling happens without freezing the q, this\ncan easily happen while some IOs are in flight and thus leak the counts.\n\nThis can be easily demonstrated by turning on iolatency on an one empty\ncgroup while IOs are in flight in other cgroups and then removing the\ncgroup. Note that iolatency shouldn't have been enabled elsewhere in the\nsystem to ensure that removing the cgroup disables iolatency for the whole\ndevice.\n\nThe following keeps flipping on and off iolatency on sda:\n\n  echo +io > /sys/fs/cgroup/cgroup.subtree_control\n  while true; do\n      mkdir -p /sys/fs/cgroup/test\n      echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency\n      sleep 1\n      rmdir /sys/fs/cgroup/test\n      sleep 1\n  done\n\nand there's concurrent fio generating direct rand reads:\n\n  fio --name test --filename=/dev/sda --direct=1 --rw=randread \\\n      --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k\n\nwhile monitoring with the following drgn script:\n\n  while True:\n    for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()):\n        for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list):\n            blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node')\n            pd = blkg.pd[prog['blkcg_policy_iolatency'].plid]\n            if pd.value_() == 0:\n                continue\n            iolat = container_of(pd, 'struct iolatency_grp', 'pd')\n            inflight = iolat.rq_wait.inflight.counter.value_()\n            if inflight:\n                print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} '\n                      f'{cgroup_path(css.cgroup).decode("utf-8")}')\n    time.sleep(1)\n\nThe monitoring output looks like the following:\n\n  inflight=1 sda /user.slice\n  inflight=1 sda /user.slice\n  ...\n  inflight=14 sda /user.slice\n  inflight=13 sda /user.slice\n  inflight=17 sda /user.slice\n  inflight=15 sda /user.slice\n  inflight=18 sda /user.slice\n  inflight=17 sda /user.slice\n  inflight=20 sda /user.slice\n  inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19\n  inflight=19 sda /user.slice\n  inflight=19 sda /user.slice\n\nIf a cgroup with stuck inflight ends up getting throttled, the throttled IOs\nwill never get issued as there's no completion event to wake it up leading\nto an indefinite hang.\n\nThis patch fixes the bug by unifying enable handling into a work item which\nis automatically kicked off from iolatency_set_min_lat_nsec() which is\ncalled from both iolatency_set_limit() and iolatency_pd_offline() paths.\nPunting to a work item is necessary as iolatency_pd_offline() is called\nunder spinlocks while freezing a request_queue requires a sleepable context.\n\nThis also simplifies the code reducing LOC sans the comments and avoids the\nunnecessary freezes which were happening whenever a cgroup's latency target\nis newly set or cleared.(CVE-2022-49394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages.  In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared.  The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh  pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G    B              6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n  show_stack+0x20/0x38 (C)\n  dump_stack_lvl+0x80/0xf8\n  dump_stack+0x18/0x28\n  bad_page+0x8c/0x130\n  free_page_is_bad_report+0xa4/0xb0\n  free_unref_page+0x3cc/0x620\n  __folio_put+0xf4/0x158\n  split_huge_pages_all+0x1e0/0x3e8\n  split_huge_pages_write+0x25c/0x2d8\n  full_proxy_write+0x64/0xd8\n  vfs_write+0xcc/0x280\n  ksys_write+0x70/0x110\n  __arm64_sys_write+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x34/0x128\n  el0t_64_sync_handler+0xc8/0xd0\n  el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n   "nonzero mapcount".\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n   treat the page table as shared and a shared page table will not be\n   unmapped.\n\nFix it by introducing independent PMD page table shared count.  As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: fix soft lockup in the OOM process\n\nA soft lockup issue was found in the product with about 56,000 tasks were\nin the OOM cgroup, it was traversing them when the soft lockup was\ntriggered.\n\nwatchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]\nCPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G\nHardware name: Huawei Cloud OpenStack Nova, BIOS\nRIP: 0010:console_unlock+0x343/0x540\nRSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13\nRAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247\nRBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040\nR10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0\nR13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n vprintk_emit+0x193/0x280\n printk+0x52/0x6e\n dump_task+0x114/0x130\n mem_cgroup_scan_tasks+0x76/0x100\n dump_header+0x1fe/0x210\n oom_kill_process+0xd1/0x100\n out_of_memory+0x125/0x570\n mem_cgroup_out_of_memory+0xb5/0xd0\n try_charge+0x720/0x770\n mem_cgroup_try_charge+0x86/0x180\n mem_cgroup_try_charge_delay+0x1c/0x40\n do_anonymous_page+0xb5/0x390\n handle_mm_fault+0xc4/0x1f0\n\nThis is because thousands of processes are in the OOM cgroup, it takes a\nlong time to traverse all of them.  As a result, this lead to soft lockup\nin the OOM process.\n\nTo fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks'\nfunction per 1000 iterations.  For global OOM, call\n'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.(CVE-2024-57977)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: don't allow reconnect after disconnect\n\nFollowing process can cause nbd_config UAF:\n\n1) grab nbd_config temporarily;\n\n2) nbd_genl_disconnect() flush all recv_work() and release the\ninitial reference:\n\n  nbd_genl_disconnect\n   nbd_disconnect_and_put\n    nbd_disconnect\n     flush_workqueue(nbd->recv_workq)\n    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))\n     nbd_config_put\n     -> due to step 1), reference is still not zero\n\n3) nbd_genl_reconfigure() queue recv_work() again;\n\n  nbd_genl_reconfigure\n   config = nbd_get_config_unlocked(nbd)\n   if (!config)\n   -> succeed\n   if (!test_bit(NBD_RT_BOUND, ...))\n   -> succeed\n   nbd_reconnect_socket\n    queue_work(nbd->recv_workq, &args->work)\n\n4) step 1) release the reference;\n\n5) Finially, recv_work() will trigger UAF:\n\n  recv_work\n   nbd_config_put(nbd)\n   -> nbd_config is freed\n   atomic_dec(&config->recv_threads)\n   -> UAF\n\nFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so\nthat nbd_genl_reconfigure() will fail.(CVE-2025-21731)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/compaction: fix UBSAN shift-out-of-bounds warning\n\nsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)\nin isolate_freepages_block().  The bogus compound_order can be any value\nbecause it is union with flags.  Add back the MAX_PAGE_ORDER check to fix\nthe warning.(CVE-2025-21815)","modified":"2026-03-11T07:05:23.679040Z","published":"2025-03-07T15:27:03Z","upstream":["CVE-2021-47652","CVE-2022-49073","CVE-2022-49091","CVE-2022-49394","CVE-2024-57883","CVE-2024-57977","CVE-2025-21731","CVE-2025-21815"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1245"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49091"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49394"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21731"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21815"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2503.1.0.0318.oe2003sp4"}]}],"ecosystem_specific":{"x86_64":["bpftool-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","perf-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.x86_64.rpm"],"src":["kernel-4.19.90-2503.1.0.0318.oe2003sp4.src.rpm"],"aarch64":["bpftool-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","perf-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2503.1.0.0318.oe2003sp4.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-1245.json"}}],"schema_version":"1.7.5"}