{"schema_version":"1.7.2","id":"OESA-2025-1924","modified":"2025-08-01T13:02:39Z","published":"2025-08-01T13:02:39Z","upstream":["CVE-2022-49535","CVE-2022-50098","CVE-2025-38015","CVE-2025-38035","CVE-2025-38324","CVE-2025-38391","CVE-2025-38466"],"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\nscsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI\n\nIf lpfc_issue_els_flogi() fails and returns non-zero status, the node\nreference count is decremented to trigger the release of the nodelist\nstructure. However, if there is a prior registration or dev-loss-evt work\npending, the node may be released prematurely.  When dev-loss-evt\ncompletes, the released node is referenced causing a use-after-free null\npointer dereference.\n\nSimilarly, when processing non-zero ELS PLOGI completion status in\nlpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport\nregistration before triggering node removal.  If dev-loss-evt work is\npending, the node may be released prematurely and a subsequent call to\nlpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.\n\nAdd test for pending dev-loss before decrementing the node reference count\nfor FLOGI, PLOGI, PRLI, and ADISC handling.(CVE-2022-49535)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts\n\nEnsure SRB is returned during I/O timeout error escalation. If that is not\npossible fail the escalation path.\n\nFollowing crash stack was seen:\n\nBUG: unable to handle kernel paging request at 0000002f56aa90f8\nIP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]\nCall Trace:\n ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]\n ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]\n ? dma_pool_alloc+0x1d6/0x210\n ? mempool_alloc+0x54/0x130\n ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]\n ? qla_do_work+0x2d/0x40 [qla2xxx]\n ? process_one_work+0x14c/0x390(CVE-2022-50098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: fix memory leak in error handling path of idxd_alloc\n\nMemory allocated for idxd is not freed if an error occurs during\nidxd_alloc(). To fix it, free the allocated memory in the reverse order\nof allocation before exiting the function in case of an error.(CVE-2025-38015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: don't restore null sk_state_change\n\nqueue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if\nthe TCP connection isn't established when nvmet_tcp_set_queue_sock() is\ncalled then queue->state_change isn't set and sock->sk->sk_state_change\nisn't replaced.\n\nAs such we don't need to restore sock->sk->sk_state_change if\nqueue->state_change is NULL.\n\nThis avoids NULL pointer dereferences such as this:\n\n[  286.462026][    C0] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[  286.462814][    C0] #PF: supervisor instruction fetch in kernel mode\n[  286.463796][    C0] #PF: error_code(0x0010) - not-present page\n[  286.464392][    C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0\n[  286.465086][    C0] Oops: Oops: 0010 [#1] SMP KASAN PTI\n[  286.465559][    C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)\n[  286.466393][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n[  286.467147][    C0] RIP: 0010:0x0\n[  286.467420][    C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[  286.467977][    C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246\n[  286.468425][    C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43\n[  286.469019][    C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100\n[  286.469545][    C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c\n[  286.470072][    C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3\n[  286.470585][    C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268\n[  286.471070][    C0] FS:  00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000\n[  286.471644][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  286.472543][    C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0\n[  286.473500][    C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  286.474467][    C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400\n[  286.475453][    C0] Call Trace:\n[  286.476102][    C0]  <IRQ>\n[  286.476719][    C0]  tcp_fin+0x2bb/0x440\n[  286.477429][    C0]  tcp_data_queue+0x190f/0x4e60\n[  286.478174][    C0]  ? __build_skb_around+0x234/0x330\n[  286.478940][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.479659][    C0]  ? __pfx_tcp_data_queue+0x10/0x10\n[  286.480431][    C0]  ? tcp_try_undo_loss+0x640/0x6c0\n[  286.481196][    C0]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90\n[  286.482046][    C0]  ? kvm_clock_get_cycles+0x14/0x30\n[  286.482769][    C0]  ? ktime_get+0x66/0x150\n[  286.483433][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.484146][    C0]  tcp_rcv_established+0x6e4/0x2050\n[  286.484857][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.485523][    C0]  ? ipv4_dst_check+0x160/0x2b0\n[  286.486203][    C0]  ? __pfx_tcp_rcv_established+0x10/0x10\n[  286.486917][    C0]  ? lock_release+0x217/0x2c0\n[  286.487595][    C0]  tcp_v4_do_rcv+0x4d6/0x9b0\n[  286.488279][    C0]  tcp_v4_rcv+0x2af8/0x3e30\n[  286.488904][    C0]  ? raw_local_deliver+0x51b/0xad0\n[  286.489551][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.490198][    C0]  ? __pfx_tcp_v4_rcv+0x10/0x10\n[  286.490813][    C0]  ? __pfx_raw_local_deliver+0x10/0x10\n[  286.491487][    C0]  ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]\n[  286.492275][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.492900][    C0]  ip_protocol_deliver_rcu+0x8f/0x370\n[  286.493579][    C0]  ip_local_deliver_finish+0x297/0x420\n[  286.494268][    C0]  ip_local_deliver+0x168/0x430\n[  286.494867][    C0]  ? __pfx_ip_local_deliver+0x10/0x10\n[  286.495498][    C0]  ? __pfx_ip_local_deliver_finish+0x10/0x10\n[  286.496204][    C0]  ? ip_rcv_finish_core+0x19a/0x1f20\n[  286.496806][    C0]  ? lock_release+0x217/0x2c0\n[  286.497414][    C0]  ip_rcv+0x455/0x6e0\n[  286.497945][    C0]  ? __pfx_ip_rcv+0x10/0x10\n[ \n---truncated---(CVE-2025-38035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().\n\nAs syzbot reported [0], mpls_route_input_rcu() can be called\nfrom mpls_getroute(), where is under RTNL.\n\nnet->mpls.platform_label is only updated under RTNL.\n\nLet's use rcu_dereference_rtnl() in mpls_route_input_rcu() to\nsilence the splat.\n\n[0]:\nWARNING: suspicious RCU usage\n6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted\n ----------------------------\nnet/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by syz.2.4451/17730:\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865\n mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84\n mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381\n rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964\n netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmmsg+0x200/0x420 net/socket.c:2709\n __do_sys_sendmmsg net/socket.c:2736 [inline]\n __se_sys_sendmmsg net/socket.c:2733 [inline]\n __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f0a2818e969\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133\nRAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969\nRDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003\nRBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268\n </TASK>(CVE-2025-38324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmodes/displayport: do not index invalid pin_assignments\n\nA poorly implemented DisplayPort Alt Mode port partner can indicate\nthat its pin assignment capabilities are greater than the maximum\nvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show\nwill cause a BRK exception due to an out of bounds array access.\n\nPrevent for loop in pin_assignment_show from accessing\ninvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX\nvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop\ncondition.(CVE-2025-38391)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Revert to requiring CAP_SYS_ADMIN for uprobes\n\nJann reports that uprobes can be used destructively when used in the\nmiddle of an instruction. The kernel only verifies there is a valid\ninstruction at the requested offset, but due to variable instruction\nlength cannot determine if this is an instruction as seen by the\nintended execution stream.\n\nAdditionally, Mark Rutland notes that on architectures that mix data\nin the text segment (like arm64), a similar things can be done if the\ndata word is 'mistaken' for an instruction.\n\nAs such, require CAP_SYS_ADMIN for uprobes.(CVE-2025-38466)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-275.0.0.177.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","perf-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-275.0.0.177.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-275.0.0.177.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","perf-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-275.0.0.177.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49535"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38324"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38391"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38466"}],"database_specific":{"severity":"High"}}