{"schema_version":"1.7.2","id":"OESA-2025-2407","modified":"2025-10-11T13:21:08Z","published":"2025-10-11T13:21:08Z","upstream":["CVE-2022-49234","CVE-2022-50350","CVE-2022-50404","CVE-2023-53165","CVE-2023-53241","CVE-2023-53259","CVE-2023-53275","CVE-2023-53286","CVE-2023-53331","CVE-2023-53369","CVE-2023-53384","CVE-2023-53395","CVE-2023-53438","CVE-2025-21801","CVE-2025-22073","CVE-2025-38086","CVE-2025-38313","CVE-2025-38615","CVE-2025-39752","CVE-2025-39865","CVE-2025-39866","CVE-2025-39883"],"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\nnet: dsa: Avoid cross-chip syncing of VLAN filtering\n\nChanges to VLAN filtering are not applicable to cross-chip\nnotifications.\n\nOn a system like this:\n\n.-----.   .-----.   .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n'-1-2-'   '-1-2-'   '-1-2-'\n\nBefore this change, upon sw1p1 leaving a bridge, a call to\ndsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.\n\nIn this scenario:\n\n.---------.   .-----.   .-----.\n|   sw1   +---+ sw2 +---+ sw3 |\n'-1-2-3-4-'   '-1-2-'   '-1-2-'\n\nWhen sw1p4 would leave a bridge, dsa_port_vlan_filtering would be\ncalled for sw2 and sw3 with a non-existing port - leading to array\nout-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 ("fbdev: fbcon: Properly revert changes when\nvc_resize() failed") missed that the buffer might be newly allocated\nby fbcon_set_font().(CVE-2022-50404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix uninitialized array access for some pathnames\n\nFor filenames that begin with . and are between 2 and 5 characters long,\nUDF charset conversion code would read uninitialized memory in the\noutput buffer. The only practical impact is that the name may be prepended a\n"unification hash" when it is not actually needed but still it is good\nto fix this.(CVE-2023-53165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call op_release, even when op_func returns an error\n\nFor ops with "trivial" replies, nfsd4_encode_operation will shortcut\nmost of the encoding work and skip to just marshalling up the status.\nOne of the things it skips is calling op_release. This could cause a\nmemory leak in the layoutget codepath if there is an error at an\ninopportune time.\n\nHave the compound processing engine always call op_release, even when\nop_func sets an error in op->status. With this change, we also need\nnfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL\non error to avoid a double free.(CVE-2023-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context->notify_page causing a GPF. To avoid GPF check if\ncontext->notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n    0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n    0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n <TASK>\n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()\n\nThe variable codec->regmap is often protected by the lock\ncodec->regmap_lock when is accessed. However, it is accessed without\nholding the lock when is accessed in snd_hdac_regmap_sync():\n\n  if (codec->regmap)\n\nIn my opinion, this may be a harmful race, because if codec->regmap is\nset to NULL right after the condition is checked, a null-pointer\ndereference can occur in the called function regcache_sync():\n\n  map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c\n\nTo fix this possible null-pointer dereference caused by data race, the\nmutex_lock coverage is extended to protect the if statement as well as the\nfunction call to regcache_sync().\n\n[ Note: the lack of the regmap_lock itself is harmless for the current\n  codec driver implementations, as snd_hdac_regmap_sync() is only for\n  PM runtime resume that is prohibited during the codec probe.\n  But the change makes the whole code more consistent, so it's merged\n  as is -- tiwai ](CVE-2023-53275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Return the firmware result upon destroying QP/RQ\n\nPreviously when destroying a QP/RQ, the result of the firmware\ndestruction function was ignored and upper layers weren't informed\nabout the failure.\nWhich in turn could lead to various problems since when upper layer\nisn't aware of the failure it continues its operation thinking that the\nrelated QP/RQ was successfully destroyed while it actually wasn't,\nwhich could lead to the below kernel WARN.\n\nCurrently, we return the correct firmware destruction status to upper\nlayers which in case of the RQ would be mlx5_ib_destroy_wq() which\nwas already capable of handling RQ destruction failure or in case of\na QP to destroy_qp_common(), which now would actually warn upon qp\ndestruction failure.\n\nWARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nModules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse\nCPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nCode: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f\nRSP: 0018:ffff8881533e3e78 EFLAGS: 00010287\nRAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000\nRDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0\nRBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009\nR10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780\nR13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000\nFS:  00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ib_uverbs_close+0x1a/0x90 [ib_uverbs]\n __fput+0x82/0x230\n task_work_run+0x59/0x90\n exit_to_user_mode_prepare+0x138/0x140\n syscall_exit_to_user_mode+0x1d/0x50\n ? __x64_sys_close+0xe/0x40\n do_syscall_64+0x4a/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f8be3ae0abb\nCode: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44\nRSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003\nRAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb\nRDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005\nRBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8\nR13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020\n </TASK>(CVE-2023-53286)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npstore/ram: Check start of empty przs during init\n\nAfter commit 30696378f68a ("pstore/ram: Do not treat empty buffers as\nvalid"), initialization would assume a prz was valid after seeing that\nthe buffer_size is zero (regardless of the buffer start position). This\nunchecked start value means it could be outside the bounds of the buffer,\nleading to future access panics when written to:\n\n sysdump_panic_event+0x3b4/0x5b8\n atomic_notifier_call_chain+0x54/0x90\n panic+0x1c8/0x42c\n die+0x29c/0x2a8\n die_kernel_fault+0x68/0x78\n __do_kernel_fault+0x1c4/0x1e0\n do_bad_area+0x40/0x100\n do_translation_fault+0x68/0x80\n do_mem_abort+0x68/0xf8\n el1_da+0x1c/0xc0\n __raw_writeb+0x38/0x174\n __memcpy_toio+0x40/0xac\n persistent_ram_update+0x44/0x12c\n persistent_ram_write+0x1a8/0x1b8\n ramoops_pstore_write+0x198/0x1e8\n pstore_console_write+0x94/0xe0\n ...\n\nTo avoid this, also check if the prz start is 0 during the initialization\nphase. If not, the next prz sanity check case will discover it (start >\nsize) and zap the buffer back to a sane state.\n\n[kees: update commit log with backtrace and clarifications](CVE-2023-53331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dcb: choose correct policy to parse DCB_ATTR_BCN\n\nThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],\nwhich is introduced in commit 859ee3c43812 ("DCB: Add support for DCB\nBCN"). Please see the comment in below code\n\nstatic int dcbnl_bcn_setcfg(...)\n{\n  ...\n  ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )\n  // !!! dcbnl_pfc_up_nest for attributes\n  //  DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs\n  ...\n  for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) {\n  // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs\n    ...\n    value_byte = nla_get_u8(data[i]);\n    ...\n  }\n  ...\n  for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) {\n  // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs\n  ...\n    value_int = nla_get_u32(data[i]);\n  ...\n  }\n  ...\n}\n\nThat is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest\nattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the\nfollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.\nBy looking up the associated nla_policy for dcbnl_bcn_attrs. We can find\nthe beginning part of these two policies are "same".\n\nstatic const struct nla_policy dcbnl_pfc_up_nest[...] = {\n        [DCB_PFC_UP_ATTR_0]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_1]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_2]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_3]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_4]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_5]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_6]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_7]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nstatic const struct nla_policy dcbnl_bcn_nest[...] = {\n        [DCB_BCN_ATTR_RP_0]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_1]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_2]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_3]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_4]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_5]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_6]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_7]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_ALL]       = {.type = NLA_FLAG},\n        // from here is somewhat different\n        [DCB_BCN_ATTR_BCNA_0]       = {.type = NLA_U32},\n        ...\n        [DCB_BCN_ATTR_ALL]          = {.type = NLA_FLAG},\n};\n\nTherefore, the current code is buggy and this\nnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use\nthe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.\n\nHence use the correct policy dcbnl_bcn_nest to parse the nested\ntb[DCB_ATTR_BCN] TLV.(CVE-2023-53369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn 'mwifiex_handle_uap_rx_forward()', always check the value\nreturned by 'skb_copy()' to avoid potential NULL pointer\ndereference in 'mwifiex_uap_queue_bridged_pkt()', and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter](CVE-2023-53395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE: Always save CS register on AMD Zen IF Poison errors\n\nThe Instruction Fetch (IF) units on current AMD Zen-based systems do not\nguarantee a synchronous #MC is delivered for poison consumption errors.\nTherefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the\nmicroarchitecture does guarantee that the exception is delivered within\nthe same context. In other words, the exact rIP is not known, but the\ncontext is known to not have changed.\n\nThere is no architecturally-defined method to determine this behavior.\n\nThe Code Segment (CS) register is always valid on such IF unit poison\nerrors regardless of the value of MCG_STATUS[EIPV|RIPV].\n\nAdd a quirk to save the CS register for poison consumption from the IF\nunit banks.\n\nThis is needed to properly determine the context of the error.\nOtherwise, the severity grading function will assume the context is\nIN_KERNEL due to the m->cs value being 0 (the initialized value). This\nleads to unnecessary kernel panics on data poison errors due to the\nkernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[   39.032969] =============================\n[   39.032983] WARNING: suspicious RCU usage\n[   39.033019] -----------------------------\n[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[   39.033597] stack backtrace:\n[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[   39.033628] Call trace:\n[   39.033633]  show_stack+0x14/0x1c (C)\n[   39.033652]  dump_stack_lvl+0xb4/0xc4\n[   39.033664]  dump_stack+0x14/0x1c\n[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c\n[   39.033682]  phy_detach+0x160/0x190\n[   39.033694]  phy_disconnect+0x40/0x54\n[   39.033703]  ravb_close+0x6c/0x1cc\n[   39.033714]  ravb_suspend+0x48/0x120\n[   39.033721]  dpm_run_callback+0x4c/0x14c\n[   39.033731]  device_suspend+0x11c/0x4dc\n[   39.033740]  dpm_suspend+0xdc/0x214\n[   39.033748]  dpm_suspend_start+0x48/0x60\n[   39.033758]  suspend_devices_and_enter+0x124/0x574\n[   39.033769]  pm_suspend+0x1ac/0x274\n[   39.033778]  state_store+0x88/0x124\n[   39.033788]  kobj_attr_store+0x14/0x24\n[   39.033798]  sysfs_kf_write+0x48/0x6c\n[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8\n[   39.033817]  vfs_write+0x27c/0x378\n[   39.033825]  ksys_write+0x64/0xf4\n[   39.033833]  __arm64_sys_write+0x18/0x20\n[   39.033841]  invoke_syscall+0x44/0x104\n[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4\n[   39.033862]  do_el0_svc+0x18/0x20\n[   39.033870]  el0_svc+0x3c/0xf0\n[   39.033880]  el0t_64_sync_handler+0xc0/0xc4\n[   39.033888]  el0t_64_sync+0x154/0x158\n[   39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt's called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure.  That does remove everything\nwe'd managed to create, but... the problem dentry is still\nnegative.  IOW, it needs to be explicitly dropped.(CVE-2025-22073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called "buff", which is initialised\nwith control_read(). However "buff" is conditionally\ninitialised inside control_read():\n\n        if (err == size) {\n                memcpy(data, buf, size);\n        }\n\nIf the condition of "err == size" is not met, then\n"buff" remains uninitialised. Once this happens the\nuninitialised "buff" is accessed and returned during\nch9200_mdio_read():\n\n        return (buff[0] | buff[1] << 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of "buff".\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix double-free on mc_dev\n\nThe blamed commit tried to simplify how the deallocations are done but,\nin the process, introduced a double-free on the mc_dev variable.\n\nIn case the MC device is a DPRC, a new mc_bus is allocated and the\nmc_dev variable is just a reference to one of its fields. In this\ncircumstance, on the error path only the mc_bus should be freed.\n\nThis commit introduces back the following checkpatch warning which is a\nfalse-positive.\n\nWARNING: kfree(NULL) is safe and this check is probably not required\n+       if (mc_bus)\n+               kfree(mc_bus);(CVE-2025-38313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: cancle set bad inode after removing name fails\n\nThe reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.\nWhen renaming, the file0's inode is marked as a bad inode because the file\nname cannot be deleted.\n\nThe underlying bug is that make_bad_inode() is called on a live inode.\nIn some cases it's "icache lookup finds a normal inode, d_splice_alias()\nis called to attach it to dentry, while another thread decides to call\nmake_bad_inode() on it - that would evict it from icache, but we'd already\nfound it there earlier".\nIn some it's outright "we have an inode attached to dentry - that's how we\ngot it in the first place; let's call make_bad_inode() on it just for shits\nand giggles".(CVE-2025-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn't expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[    0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: fix NULL pointer dereference in tee_shm_put\n\ntee_shm_put have NULL pointer dereference:\n\n__optee_disable_shm_cache -->\n\tshm = reg_pair_to_ptr(...);//shm maybe return NULL\n        tee_shm_free(shm); -->\n\t\ttee_shm_put(shm);//crash\n\nAdd check in tee_shm_put to fix it.\n\npanic log:\nUnable to handle kernel paging request at virtual address 0000000000100cca\nMem abort info:\nESR = 0x0000000096000004\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x04: level 0 translation fault\nData abort info:\nISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000\n[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----\n6.6.0-39-generic #38\nSource Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07\nHardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0\n10/26/2022\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tee_shm_put+0x24/0x188\nlr : tee_shm_free+0x14/0x28\nsp : ffff001f98f9faf0\nx29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000\nx26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048\nx23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88\nx20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff\nx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003\nx14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101\nx11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c\nx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca\nCall trace:\ntee_shm_put+0x24/0x188\ntee_shm_free+0x14/0x28\n__optee_disable_shm_cache+0xa8/0x108\noptee_shutdown+0x28/0x38\nplatform_shutdown+0x28/0x40\ndevice_shutdown+0x144/0x2b0\nkernel_power_off+0x3c/0x80\nhibernate+0x35c/0x388\nstate_store+0x64/0x80\nkobj_attr_store+0x14/0x28\nsysfs_kf_write+0x48/0x60\nkernfs_fop_write_iter+0x128/0x1c0\nvfs_write+0x270/0x370\nksys_write+0x6c/0x100\n__arm64_sys_write+0x20/0x30\ninvoke_syscall+0x4c/0x120\nel0_svc_common.constprop.0+0x44/0xf0\ndo_el0_svc+0x24/0x38\nel0_svc+0x24/0x88\nel0t_64_sync_handler+0x134/0x150\nel0t_64_sync+0x14c/0x15(CVE-2025-39865)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n </TASK>\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered.  This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline > /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)","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-284.0.0.186.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-284.0.0.186.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50404"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53165"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53241"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53259"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53286"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53331"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53369"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53384"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53395"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53438"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38615"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39865"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39866"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39883"}],"database_specific":{"severity":"High"}}