An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2885 Final 1.0 1.0 2025-12-30 Initial 2025-12-30 2025-12-30 openEuler SA Tool V1.0 2025-12-30 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().(CVE-2022-49121) In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: <IRQ>kernel: dump_stack+0x66/0x81kernel: __schedule_bug.cold.90+0x5/0x1dkernel: __schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: schedule_timeout+0x26d/0x3b0kernel: wait_for_completion+0xb4/0x140kernel: ? wake_up_q+0x70/0x70kernel: __wait_rcu_gp+0x12c/0x160kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel: synchronize_sched+0x6c/0x80kernel: ? call_rcu_bh+0x20/0x20kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]kernel: device_for_each_child+0x54/0x90kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel: __handle_irq_event_percpu+0x40/0x180kernel: handle_irq_event_percpu+0x30/0x80kernel: handle_irq_event+0x36/0x60(CVE-2022-49156) In the Linux kernel, the following vulnerability has been resolved: uaccess: fix integer overflow on access_ok() Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not. Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289) In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inline_dots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfolio_mark_dirty+0x33/0x50f2fs_add_regular_entry+0x541/0xad0 [f2fs]f2fs_add_dentry+0x6c/0xb0 [f2fs]f2fs_do_add_link+0x182/0x230 [f2fs]__recover_dot_dentries+0x2d6/0x470 [f2fs]f2fs_lookup+0x5af/0x6a0 [f2fs]__lookup_slow+0xac/0x200lookup_slow+0x45/0x70walk_component+0x16c/0x250path_lookupat+0x8b/0x1f0filename_lookup+0xef/0x250user_path_at_empty+0x46/0x70vfs_statx+0x98/0x190__do_sys_newlstat+0x41/0x90__x64_sys_newlstat+0x1a/0x30do_syscall_64+0x37/0xb0entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping->a_ops field, so, in a fuzzed image, if inline_dots flag wastagged in special file, during lookup(), when f2fs runs into__recover_dot_dentries(), it will cause NULL pointer access oncef2fs_add_regular_entry() calls a_ops->set_dirty_page().(CVE-2022-49428) In the Linux kernel, the following vulnerability has been resolved:arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscallIf a compat process tries to execute an unknown system call above the__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to theoffending process. Information about the error is printed to dmesg incompat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->arm64_show_signal().arm64_show_signal() interprets a non-zero value forcurrent->thread.fault_code as an exception syndrome and displays themessage associated with the ESR_ELx.EC field (bits 31:26).current->thread.fault_code is set in compat_arm_syscall() ->arm64_notify_die() with the bad syscall number instead of a valid ESR_ELxvalue. This means that the ESR_ELx.EC field has the value that the user setfor the syscall number and the kernel can end up printing bogus exceptionmessages*. For example, for the syscall number 0x68000000, which evaluatesto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000][ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79[ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which is misleading, as the bad compat syscall has nothing to do withpointer authentication.Stop arm64_show_signal() from printing exception syndrome information byhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has nomeaning for an invalid system call number. The example above now becomes:[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000][ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80[ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which although shows less information because the syscall number,wrongfully advertised as the ESR value, is missing, it is better thanshowing plainly wrong information. The syscall number can be easilyobtained with strace.*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negativeinteger in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_ENDevaluates to true; the syscall will exit to userspace in this case with theENOSYS error code instead of arm64_notify_die() being called.(CVE-2022-49520) In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_probe_threshold.While reading sysctl_tcp_probe_threshold, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.(CVE-2022-49595) In the Linux kernel, the following vulnerability has been resolved: mmc: core: Fix kernel panic when remove non-standard SDIO card SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdio_init_func(), but all SDIO card device reference counter gets decreased at sdio_release_func().(CVE-2022-50640) In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Perform lockless command completion in abort path While adding and removing the controller, the following call trace was observed: WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50 Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held.(CVE-2023-53041) In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.(CVE-2023-53248) In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835) In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow assignment in link_dp_ctssampling_rate is an uint8_t but is assigned an unsigned int, and thus itcan overflow. As a result, sampling_rate is changed to uint32_t.Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it shouldonly be assigned to a value less or equal than 4.This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016) In the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn t being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here s a debug log of the indicent:[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[ 12.052207] ieee80211 phy0: il4965_mac_start enter[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready[ 12.052324] ieee80211 phy0: il_apm_init Init card s basic functions[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.[ 12.058869] ieee80211 phy0: Hardware restart was requested[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.[ 16.132303] ------------[ cut here ]------------[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[ 16.132463] Workqueue: async async_run_entry_fn[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132501] Code: da 02 00 0---truncated---(CVE-2024-50234) In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744) In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.(CVE-2025-21776) In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this.(CVE-2025-38516) An update for kernel is now available for openEuler-20.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49121 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49156 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49289 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49428 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49520 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-49595 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50640 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53041 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53248 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-43835 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50016 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50234 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21744 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21776 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38516 https://nvd.nist.gov/vuln/detail/CVE-2022-49121 https://nvd.nist.gov/vuln/detail/CVE-2022-49156 https://nvd.nist.gov/vuln/detail/CVE-2022-49289 https://nvd.nist.gov/vuln/detail/CVE-2022-49428 https://nvd.nist.gov/vuln/detail/CVE-2022-49520 https://nvd.nist.gov/vuln/detail/CVE-2022-49595 https://nvd.nist.gov/vuln/detail/CVE-2022-50640 https://nvd.nist.gov/vuln/detail/CVE-2023-53041 https://nvd.nist.gov/vuln/detail/CVE-2023-53248 https://nvd.nist.gov/vuln/detail/CVE-2024-43835 https://nvd.nist.gov/vuln/detail/CVE-2024-50016 https://nvd.nist.gov/vuln/detail/CVE-2024-50234 https://nvd.nist.gov/vuln/detail/CVE-2025-21744 https://nvd.nist.gov/vuln/detail/CVE-2025-21776 https://nvd.nist.gov/vuln/detail/CVE-2025-38516 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm kernel-4.19.90-2512.4.0.0356.oe2003sp4.src.rpm bpftool-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free(). 2025-12-30 CVE-2022-49121 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: <IRQ>kernel: dump_stack+0x66/0x81kernel: __schedule_bug.cold.90+0x5/0x1dkernel: __schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: schedule_timeout+0x26d/0x3b0kernel: wait_for_completion+0xb4/0x140kernel: ? wake_up_q+0x70/0x70kernel: __wait_rcu_gp+0x12c/0x160kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel: synchronize_sched+0x6c/0x80kernel: ? call_rcu_bh+0x20/0x20kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]kernel: device_for_each_child+0x54/0x90kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel: __handle_irq_event_percpu+0x40/0x180kernel: handle_irq_event_percpu+0x30/0x80kernel: handle_irq_event+0x36/0x60 2025-12-30 CVE-2022-49156 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved: uaccess: fix integer overflow on access_ok() Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not. Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison. 2025-12-30 CVE-2022-49289 openEuler-20.03-LTS-SP4 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inline_dots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfolio_mark_dirty+0x33/0x50f2fs_add_regular_entry+0x541/0xad0 [f2fs]f2fs_add_dentry+0x6c/0xb0 [f2fs]f2fs_do_add_link+0x182/0x230 [f2fs]__recover_dot_dentries+0x2d6/0x470 [f2fs]f2fs_lookup+0x5af/0x6a0 [f2fs]__lookup_slow+0xac/0x200lookup_slow+0x45/0x70walk_component+0x16c/0x250path_lookupat+0x8b/0x1f0filename_lookup+0xef/0x250user_path_at_empty+0x46/0x70vfs_statx+0x98/0x190__do_sys_newlstat+0x41/0x90__x64_sys_newlstat+0x1a/0x30do_syscall_64+0x37/0xb0entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping->a_ops field, so, in a fuzzed image, if inline_dots flag wastagged in special file, during lookup(), when f2fs runs into__recover_dot_dentries(), it will cause NULL pointer access oncef2fs_add_regular_entry() calls a_ops->set_dirty_page(). 2025-12-30 CVE-2022-49428 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscallIf a compat process tries to execute an unknown system call above the__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to theoffending process. Information about the error is printed to dmesg incompat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->arm64_show_signal().arm64_show_signal() interprets a non-zero value forcurrent->thread.fault_code as an exception syndrome and displays themessage associated with the ESR_ELx.EC field (bits 31:26).current->thread.fault_code is set in compat_arm_syscall() ->arm64_notify_die() with the bad syscall number instead of a valid ESR_ELxvalue. This means that the ESR_ELx.EC field has the value that the user setfor the syscall number and the kernel can end up printing bogus exceptionmessages*. For example, for the syscall number 0x68000000, which evaluatesto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000][ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79[ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which is misleading, as the bad compat syscall has nothing to do withpointer authentication.Stop arm64_show_signal() from printing exception syndrome information byhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has nomeaning for an invalid system call number. The example above now becomes:[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000][ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80[ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which although shows less information because the syscall number,wrongfully advertised as the ESR value, is missing, it is better thanshowing plainly wrong information. The syscall number can be easilyobtained with strace.*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negativeinteger in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_ENDevaluates to true; the syscall will exit to userspace in this case with theENOSYS error code instead of arm64_notify_die() being called. 2025-12-30 CVE-2022-49520 openEuler-20.03-LTS-SP4 Low 3.3 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_probe_threshold.While reading sysctl_tcp_probe_threshold, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader. 2025-12-30 CVE-2022-49595 openEuler-20.03-LTS-SP4 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved: mmc: core: Fix kernel panic when remove non-standard SDIO card SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdio_init_func(), but all SDIO card device reference counter gets decreased at sdio_release_func(). 2025-12-30 CVE-2022-50640 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Perform lockless command completion in abort path While adding and removing the controller, the following call trace was observed: WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50 Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held. 2025-12-30 CVE-2023-53041 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them. 2025-12-30 CVE-2023-53248 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context. 2025-12-30 CVE-2024-43835 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow assignment in link_dp_ctssampling_rate is an uint8_t but is assigned an unsigned int, and thus itcan overflow. As a result, sampling_rate is changed to uint32_t.Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it shouldonly be assigned to a value less or equal than 4.This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. 2025-12-30 CVE-2024-50016 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn t being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here s a debug log of the indicent:[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[ 12.052207] ieee80211 phy0: il4965_mac_start enter[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready[ 12.052324] ieee80211 phy0: il_apm_init Init card s basic functions[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.[ 12.058869] ieee80211 phy0: Hardware restart was requested[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.[ 16.132303] ------------[ cut here ]------------[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[ 16.132463] Workqueue: async async_run_entry_fn[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132501] Code: da 02 00 0---truncated--- 2025-12-30 CVE-2024-50234 openEuler-20.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL. 2025-12-30 CVE-2025-21744 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface. 2025-12-30 CVE-2025-21776 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885 In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this. 2025-12-30 CVE-2025-38516 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-12-30 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885