<?xml version="1.0" encoding="UTF-8"?>
<updates>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-HotPatchSA-2024-1038</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47742" id="CVE-2024-47742" title="CVE-2024-47742" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from &#34;ModelName&#34;, a string that was previously parsed out of    some descriptor (&#34;Vital Product Data&#34;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, &#34;nffw.partno&#34;), which I    think parses some descriptor that was read from the device.    (But this case likely isn&#39;t exploitable because the format string looks    like &#34;netronome/nic_%s&#34;, and there shouldn&#39;t be any *folders* starting    with &#34;netronome/nic_&#34;. The previous case was different because there,    the &#34;%s&#34; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing &#34;..&#34; path components.  For what it&#39;s worth, I went looking and haven&#39;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)</description>
          <pkglist>
               <hot_patch_collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="1" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="1" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-1.x86_64.rpm</filename>
                    </package>
               </hot_patch_collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-HotPatchSA-2025-1008</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50083" id="CVE-2024-50083" title="CVE-2024-50083" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:tcp: fix mptcp DSS corruption due to large pmtu xmitSyzkaller was able to trigger a DSS corruption:  TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.  ------------[ cut here ]------------  WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695  Modules linked in:  CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024  RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695  Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 &lt;0f&gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff  RSP: 0018:ffffc90000006db8 EFLAGS: 00010246  RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00  RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0  RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8  R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000  R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5  FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  Call Trace:   &lt;IRQ&gt;   move_skbs_to_msk net/mptcp/protocol.c:811 [inline]   mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854   subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490   tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283   tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915   tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350   ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205   ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314   __netif_receive_skb_one_core net/core/dev.c:5662 [inline]   __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775   process_backlog+0x662/0x15b0 net/core/dev.c:6107   __napi_poll+0xcb/0x490 net/core/dev.c:6771   napi_poll net/core/dev.c:6840 [inline]   net_rx_action+0x89b/0x1240 net/core/dev.c:6962   handle_softirqs+0x2c5/0x980 kernel/softirq.c:554   do_softirq+0x11b/0x1e0 kernel/softirq.c:455   &lt;/IRQ&gt;   &lt;TASK&gt;   __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]   __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451   dev_queue_xmit include/linux/netdevice.h:3094 [inline]   neigh_hh_output include/net/neighbour.h:526 [inline]   neigh_output include/net/neighbour.h:540 [inline]   ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236   ip_local_out net/ipv4/ip_output.c:130 [inline]   __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536   __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]   tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752   __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015   tcp_push_pending_frames include/net/tcp.h:2107 [inline]   tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]   tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915   sk_backlog_rcv include/net/sock.h:1113 [inline]   __release_sock+0x214/0x350 net/core/sock.c:3072   release_sock+0x61/0x1f0 net/core/sock.c:3626   mptcp_push_---truncated---(CVE-2024-50083)</description>
          <pkglist>
               <hot_patch_collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="2" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-2.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="2" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-2.x86_64.rpm</filename>
                    </package>
               </hot_patch_collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-HotPatchSA-2025-1012</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21727" id="CVE-2025-21727" title="CVE-2025-21727" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:padata: fix UAF in padata_reorderA bug was found when run ltp test:BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+Workqueue: pdecrypt_parallel padata_parallel_workerCall Trace:&lt;TASK&gt;dump_stack_lvl+0x32/0x50print_address_description.constprop.0+0x6b/0x3d0print_report+0xdd/0x2c0kasan_report+0xa5/0xd0padata_find_next+0x29/0x1a0padata_reorder+0x131/0x220padata_parallel_worker+0x3d/0xc0process_one_work+0x2ec/0x5a0If &#39;mdelay(10)&#39; is added before calling &#39;padata_find_next&#39; in the&#39;padata_reorder&#39; function, this issue could be reproduced easily withltp test (pcrypt_aead01).This can be explained as bellow:pcrypt_aead_encrypt...padata_do_parallelrefcount_inc(&amp;pd-&gt;refcnt); // add refcnt...padata_do_serialpadata_reorder // pdwhile (1) {padata_find_next(pd, true); // using pdqueue_work_on...padata_serial_worker&#x9;&#x9;&#x9;&#x9;crypto_del_algpadata_put_pd_cnt // sub refcnt&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_free_shell&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_put_pd(ps-&gt;pd);&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// pd is freed// loop again, but pd is freed// call padata_find_next, UAF}In the padata_reorder function, when it loops in &#39;while&#39;, if the alg isdeleted, the refcnt may be decreased to 0 before entering&#39;padata_find_next&#39;, which leads to UAF.As mentioned in [1], do_serial is supposed to be called with BHs disabledand always happen under RCU protection, to address this issue, addsynchronize_rcu() in &#39;padata_free_shell&#39; wait for all _do_serial callsto finish.[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)</description>
          <pkglist>
               <hot_patch_collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="3" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-3.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="3" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-3.x86_64.rpm</filename>
                    </package>
               </hot_patch_collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-HotPatchSA-2025-1014</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47745" id="CVE-2024-47745" title="CVE-2024-47745" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:mm: call the security_mmap_file() LSM hook in remap_file_pages()The remap_file_pages syscall handler calls do_mmap() directly, whichdoesn&#39;t contain the LSM security check. And if the process has calledpersonality(READ_IMPLIES_EXEC) before and remap_file_pages() is called forRW pages, this will actually result in remapping the pages to RWX,bypassing a W^X policy enforced by SELinux.So we should check prot by security_mmap_file LSM hook in theremap_file_pages syscall handler before do_mmap() is called. Otherwise, itpotentially permits an attacker to bypass a W^X policy enforced bySELinux.The bypass is similar to CVE-2016-10044, which bypass the same thing viaAIO and can be found in [1].The PoC:$ cat &gt; test.cint main(void) {&#x9;size_t pagesz = sysconf(_SC_PAGE_SIZE);&#x9;int mfd = syscall(SYS_memfd_create, &#34;test&#34;, 0);&#x9;const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,&#x9;&#x9;MAP_SHARED, mfd, 0);&#x9;unsigned int old = syscall(SYS_personality, 0xffffffff);&#x9;syscall(SYS_personality, READ_IMPLIES_EXEC | old);&#x9;syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);&#x9;syscall(SYS_personality, old);&#x9;// show the RWX page exists even if W^X policy is enforced&#x9;int fd = open(&#34;/proc/self/maps&#34;, O_RDONLY);&#x9;unsigned char buf2[1024];&#x9;while (1) {&#x9;&#x9;int ret = read(fd, buf2, 1024);&#x9;&#x9;if (ret &lt;= 0) break;&#x9;&#x9;write(1, buf2, ret);&#x9;}&#x9;close(fd);}$ gcc test.c -o test$ ./test | grep rwx7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)[PM: subject line tweaks](CVE-2024-47745)</description>
          <pkglist>
               <hot_patch_collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="4" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC" release="4" version="1">
                         <filename>patch-kernel-5.10.0-216.0.0.115.oe2203sp4-ACC-1-4.x86_64.rpm</filename>
                    </package>
               </hot_patch_collection>
          </pkglist>
     </update>
</updates>