{"id":"OESA-2025-2406","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\nmemory: of: Fix refcount leak bug in of_get_ddr_timings()\n\nWe should add the of_node_put() when breaking out of\nfor_each_child_of_node() as it will automatically increase\nand decrease the refcount.(CVE-2022-50249)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Add the missed acpi_put_table() to fix memory leak\n\nWhen the radeon driver reads the bios information from ACPI\ntable in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()\nto release the ACPI memory after the init, so add acpi_put_table()\nproperly to fix the memory leak.\n\nv2: fix text formatting (Alex)(CVE-2022-50275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()\n\nThere is a global-out-of-bounds reported by KASAN:\n\n  BUG: KASAN: global-out-of-bounds in\n  _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]\n  Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411\n\n  CPU: 6 PID: 411 Comm: NetworkManager Tainted: G      D\n  6.1.0-rc8+ #144 e15588508517267d37\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),\n  Call Trace:\n   <TASK>\n   ...\n   kasan_report+0xbb/0x1c0\n   _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]\n   rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]\n   rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]\n   ...\n   </TASK>\n\nThe root cause of the problem is that the comparison order of\n"prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The\n_rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two\nstrings from tail to head, which causes the problem. In the\n_rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet\nthis requirement by carefully designing the comparison order.\nFor example, "pregulation" and "pbandwidth" are compared in order of\nlength from small to large, first is 3 and last is 4. However, the\ncomparison order of "prate_section" dose not obey such order requirement,\ntherefore when "prate_section" is "HT", when comparing from tail to head,\nit will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As\nmentioned above, the _rtl8812ae_eq_n_byte() has the same function as\nstrcmp(), so just strcmp() is enough.\n\nFix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.\nAlthough it can be fixed by adjusting the comparison order of\n"prate_section", this may cause the value of "rate_section" to not be\nfrom 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver\nfrom staging to regular tree, but also added setting txpower limit\nfunction during the driver config phase, so the problem was introduced\nby this commit.(CVE-2022-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: verify the expected usb_endpoints are present\n\nThe bug arises when a USB device claims to be an ATH9K but doesn't\nhave the expected endpoints. (In this case there was an interrupt\nendpoint where the driver expected a bulk endpoint.) The kernel\nneeds to be able to handle such devices without getting an internal error.\n\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493\nModules linked in:\nCPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nWorkqueue: events request_firmware_work_func\nRIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493\nCall Trace:\n ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]\n ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019\n ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]\n ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242\n request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097\n process_one_work+0x9af/0x1600 kernel/workqueue.c:2279\n worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425\n kthread+0x3b4/0x4a0 kernel/kthread.c:313\n ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2022-50297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS\n\nUBSAN complains about array-index-out-of-bounds:\n[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41\n[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'\n[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu\n[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010\n[ 1.980718] kernel: Call Trace:\n[ 1.980721] kernel: <TASK>\n[ 1.980723] kernel: show_stack+0x52/0x58\n[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f\n[ 1.980734] kernel: dump_stack+0x10/0x12\n[ 1.980736] kernel: ubsan_epilogue+0x9/0x45\n[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49\n[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci]\n[ 1.980748] kernel: ata_qc_issue+0x135/0x240\n[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580\n[ 1.980754] kernel: ? vprintk_default+0x1d/0x20\n[ 1.980759] kernel: ata_exec_internal+0x67/0xa0\n[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0\n[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90\n[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310\n[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0\n[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30\n[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci]\n[ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci]\n[ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci]\n[ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0\n[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560\n[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40\n[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci]\n[ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600\n[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0\n[ 1.980813] kernel: scsi_error_handler+0xa1/0x180\n[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0\n[ 1.980820] kernel: kthread+0x12a/0x150\n[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50\n[ 1.980826] kernel: ret_from_fork+0x22/0x30\n[ 1.980831] kernel: </TASK>\n\nThis happens because sata_pmp_init_links() initialize link->pmp up to\nSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.\n\nI can't find the maximum Enclosure Management ports specified in AHCI\nspec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier\nInformation" can utilize 4 bits, which implies it can support up to 16\nports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the\nissue.\n\nBugLink: https://bugs.launchpad.net/bugs/1970074(CVE-2022-50315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: cavium - prevent integer overflow loading firmware\n\nThe "code_length" value comes from the firmware file.  If your firmware\nis untrusted realistically there is probably very little you can do to\nprotect yourself.  Still we try to limit the damage as much as possible.\nAlso Smatch marks any data read from the filesystem as untrusted and\nprints warnings if it not capped correctly.\n\nThe "ntohl(ucode->code_length) * 2" multiplication can have an\ninteger overflow.(CVE-2022-50330)\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\nBluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure\n\nsyzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1],\nfor rcu_sync_enter() is called without rcu_sync_init() due to\nhci_uart_tty_open() ignoring percpu_init_rwsem() failure.\n\nWhile we are at it, fix that hci_uart_register_device() ignores\npercpu_init_rwsem() failure and hci_uart_unregister_device() does not\ncall percpu_free_rwsem().(CVE-2022-50374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: vme_user: Fix possible UAF in tsi148_dma_list_add\n\nSmatch report warning as follows:\n\ndrivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn:\n  '&entry->list' not removed from list\n\nIn tsi148_dma_list_add(), the error path "goto err_dma" will not\nremove entry->list from list->entries, but entry will be freed,\nthen list traversal may cause UAF.\n\nFix by removeing it from list->entries before free().(CVE-2022-50384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()\n\n> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);\n\nmay be schedule, and then complete before the line\n\n> ndev->stats.tx_bytes += skb->len;\n\n[   46.912801] ==================================================================\n[   46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[   46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328\n[   46.935991]\n[   46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G           O      5.4.199-[REDACTED] #1\n[   46.947255] Hardware name: [REDACTED]\n[   46.954568] Call trace:\n[   46.957037]  dump_backtrace+0x0/0x2b8\n[   46.960719]  show_stack+0x24/0x30\n[   46.964052]  dump_stack+0x128/0x194\n[   46.967557]  print_address_description.isra.0+0x64/0x380\n[   46.972877]  __kasan_report+0x1d4/0x240\n[   46.976723]  kasan_report+0xc/0x18\n[   46.980138]  __asan_report_load4_noabort+0x18/0x20\n[   46.985027]  brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[   46.990613]  dev_hard_start_xmit+0x1bc/0xda0\n[   46.994894]  sch_direct_xmit+0x198/0xd08\n[   46.998827]  __qdisc_run+0x37c/0x1dc0\n[   47.002500]  __dev_queue_xmit+0x1528/0x21f8\n[   47.006692]  dev_queue_xmit+0x24/0x30\n[   47.010366]  neigh_resolve_output+0x37c/0x678\n[   47.014734]  ip_finish_output2+0x598/0x2458\n[   47.018927]  __ip_finish_output+0x300/0x730\n[   47.023118]  ip_output+0x2e0/0x430\n[   47.026530]  ip_local_out+0x90/0x140\n[   47.030117]  igmpv3_sendpack+0x14c/0x228\n[   47.034049]  igmpv3_send_cr+0x384/0x6b8\n[   47.037895]  igmp_ifc_timer_expire+0x4c/0x118\n[   47.042262]  call_timer_fn+0x1cc/0xbe8\n[   47.046021]  __run_timers+0x4d8/0xb28\n[   47.049693]  run_timer_softirq+0x24/0x40\n[   47.053626]  __do_softirq+0x2c0/0x117c\n[   47.057387]  irq_exit+0x2dc/0x388\n[   47.060715]  __handle_domain_irq+0xb4/0x158\n[   47.064908]  gic_handle_irq+0x58/0xb0\n[   47.068581]  el0_irq_naked+0x50/0x5c\n[   47.072162]\n[   47.073665] Allocated by task 328:\n[   47.077083]  save_stack+0x24/0xb0\n[   47.080410]  __kasan_kmalloc.isra.0+0xc0/0xe0\n[   47.084776]  kasan_slab_alloc+0x14/0x20\n[   47.088622]  kmem_cache_alloc+0x15c/0x468\n[   47.092643]  __alloc_skb+0xa4/0x498\n[   47.096142]  igmpv3_newpack+0x158/0xd78\n[   47.099987]  add_grhead+0x210/0x288\n[   47.103485]  add_grec+0x6b0/0xb70\n[   47.106811]  igmpv3_send_cr+0x2e0/0x6b8\n[   47.110657]  igmp_ifc_timer_expire+0x4c/0x118\n[   47.115027]  call_timer_fn+0x1cc/0xbe8\n[   47.118785]  __run_timers+0x4d8/0xb28\n[   47.122457]  run_timer_softirq+0x24/0x40\n[   47.126389]  __do_softirq+0x2c0/0x117c\n[   47.130142]\n[   47.131643] Freed by task 180:\n[   47.134712]  save_stack+0x24/0xb0\n[   47.138041]  __kasan_slab_free+0x108/0x180\n[   47.142146]  kasan_slab_free+0x10/0x18\n[   47.145904]  slab_free_freelist_hook+0xa4/0x1b0\n[   47.150444]  kmem_cache_free+0x8c/0x528\n[   47.154292]  kfree_skbmem+0x94/0x108\n[   47.157880]  consume_skb+0x10c/0x5a8\n[   47.161466]  __dev_kfree_skb_any+0x88/0xa0\n[   47.165598]  brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]\n[   47.171023]  brcmf_txfinalize+0xec/0x190 [brcmfmac]\n[   47.176016]  brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]\n[   47.182056]  brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]\n[   47.187568]  brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]\n[   47.192529]  brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]\n[   47.197859]  process_one_work+0x7fc/0x1a80\n[   47.201965]  worker_thread+0x31c/0xc40\n[   47.205726]  kthread+0x2d8/0x370\n[   47.208967]  ret_from_fork+0x10/0x18\n[   47.212546]\n[   47.214051] The buggy address belongs to the object at ffffff803f588280\n[   47.214051]  which belongs to the cache skbuff_head_cache of size 208\n[   47.227086] The buggy address is located 104 bytes inside of\n[   47.227086]  208-byte region [ffffff803f588280, ffffff803f588350)\n[   47.238814] The buggy address belongs to the page:\n[   47.243618] page:ffffffff00dd6200 refcount:1 mapcou\n---truncated---(CVE-2022-50408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sysfs: Fix attempting to call device_add multiple times\n\ndevice_add shall not be called multiple times as stated in its\ndocumentation:\n\n 'Do not call this routine or device_register() more than once for\n any device structure'\n\nSyzkaller reports a bug as follows [1]:\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:33!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[...]\nCall Trace:\n <TASK>\n __list_add include/linux/list.h:69 [inline]\n list_add_tail include/linux/list.h:102 [inline]\n kobj_kset_join lib/kobject.c:164 [inline]\n kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214\n kobject_add_varg lib/kobject.c:358 [inline]\n kobject_add+0x150/0x1c0 lib/kobject.c:410\n device_add+0x368/0x1e90 drivers/base/core.c:3452\n hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53\n hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799\n hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110\n hci_event_func net/bluetooth/hci_event.c:7440 [inline]\n hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495\n hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007\n process_one_work+0x991/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e4/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n </TASK>(CVE-2022-50419)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Pointer may be dereferenced\n\nKlocwork tool reported pointer 'rport' returned from call to function\nfc_bsg_to_rport() may be NULL and will be dereferenced.\n\nAdd a fix to validate rport before dereferencing.(CVE-2023-53150)\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\nsched/fair: Don't balance task to its current running CPU\n\nWe've run into the case that the balancer tries to balance a migration\ndisabled task and trigger the warning in set_task_cpu() like below:\n\n ------------[ cut here ]------------\n WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240\n Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>\n CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G           O       6.1.0-rc4+ #1\n Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021\n pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : set_task_cpu+0x188/0x240\n lr : load_balance+0x5d0/0xc60\n sp : ffff80000803bc70\n x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040\n x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001\n x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78\n x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000\n x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530\n x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e\n x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a\n x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001\n Call trace:\n  set_task_cpu+0x188/0x240\n  load_balance+0x5d0/0xc60\n  rebalance_domains+0x26c/0x380\n  _nohz_idle_balance.isra.0+0x1e0/0x370\n  run_rebalance_domains+0x6c/0x80\n  __do_softirq+0x128/0x3d8\n  ____do_softirq+0x18/0x24\n  call_on_irq_stack+0x2c/0x38\n  do_softirq_own_stack+0x24/0x3c\n  __irq_exit_rcu+0xcc/0xf4\n  irq_exit_rcu+0x18/0x24\n  el1_interrupt+0x4c/0xe4\n  el1h_64_irq_handler+0x18/0x2c\n  el1h_64_irq+0x74/0x78\n  arch_cpu_idle+0x18/0x4c\n  default_idle_call+0x58/0x194\n  do_idle+0x244/0x2b0\n  cpu_startup_entry+0x30/0x3c\n  secondary_start_kernel+0x14c/0x190\n  __secondary_switched+0xb0/0xb4\n ---[ end trace 0000000000000000 ]---\n\nFurther investigation shows that the warning is superfluous, the migration\ndisabled task is just going to be migrated to its current running CPU.\nThis is because that on load balance if the dst_cpu is not allowed by the\ntask, we'll re-select a new_dst_cpu as a candidate. If no task can be\nbalanced to dst_cpu we'll try to balance the task to the new_dst_cpu\ninstead. In this case when the migration disabled task is not on CPU it\nonly allows to run on its current CPU, load balance will select its\ncurrent CPU as new_dst_cpu and later triggers the warning above.\n\nThe new_dst_cpu is chosen from the env->dst_grpmask. Currently it\ncontains CPUs in sched_group_span() and if we have overlapped groups it's\npossible to run into this case. This patch makes env->dst_grpmask of\ngroup_balance_mask() which exclude any CPUs from the busiest group and\nsolve the issue. For balancing in a domain with no overlapped groups\nthe behaviour keeps same as before.(CVE-2023-53215)\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\nudf: Do not update file length for failed writes to inline files\n\nWhen write to inline file fails (or happens only partly), we still\nupdated length of inline data as if the whole write succeeded. Fix the\nupdate of length of inline data to happen only if the write succeeds.(CVE-2023-53295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails\n\nIf getting an ID or setting up a work queue in rbd_dev_create() fails,\nuse-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts\nis triggered in do_rbd_add().  The root cause is that the ownership of\nthese structures is transfered to rbd_dev prematurely and they all end\nup getting freed when rbd_dev_create() calls rbd_dev_free() prior to\nreturning to do_rbd_add().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE, an\nincomplete patch submitted by Natalia Petrova <(CVE-2023-53307)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrecordmcount: Fix memory leaks in the uwrite function\n\nCommon realloc mistake: 'file_append' nulled but not freed upon failure(CVE-2023-53318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix BUG_ON condition in btrfs_cancel_balance\n\nPausing and canceling balance can race to interrupt balance lead to BUG_ON\npanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance\ndoes not take this race scenario into account.\n\nHowever, the race condition has no other side effects. We can fix that.\n\nReproducing it with panic trace like this:\n\n  kernel BUG at fs/btrfs/volumes.c:4618!\n  RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0\n  Call Trace:\n   <TASK>\n   ? do_nanosleep+0x60/0x120\n   ? hrtimer_nanosleep+0xb7/0x1a0\n   ? sched_core_clone_cookie+0x70/0x70\n   btrfs_ioctl_balance_ctl+0x55/0x70\n   btrfs_ioctl+0xa46/0xd20\n   __x64_sys_ioctl+0x7d/0xa0\n   do_syscall_64+0x38/0x80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n  Race scenario as follows:\n  > mutex_unlock(&fs_info->balance_mutex);\n  > --------------------\n  > .......issue pause and cancel req in another thread\n  > --------------------\n  > ret = __btrfs_balance(fs_info);\n  >\n  > mutex_lock(&fs_info->balance_mutex);\n  > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) {\n  >         btrfs_info(fs_info, "balance: paused");\n  >         btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);\n  > }(CVE-2023-53339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: Fix Oops by 9.1 surround channel names\n\nget_line_out_pfx() may trigger an Oops by overflowing the static array\nwith more than 8 channels.  This was reported for MacBookPro 12,1 with\nCirrus codec.\n\nAs a workaround, extend for the 9.1 channels and also fix the\npotential Oops by unifying the code paths accessing the same array\nwith the proper size check.(CVE-2023-53400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: net: fix use after free in fwnet_finish_incoming_packet()\n\nThe netif_rx() function frees the skb so we can't dereference it to\nsave the skb->len.(CVE-2023-53432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Handle cameras with invalid descriptors\n\nIf the source entity does not contain any pads, do not create a link.(CVE-2023-53437)\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\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\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)","modified":"2025-10-11T14:02:35.359140Z","published":"2025-10-11T13:20:57Z","upstream":["CVE-2022-50249","CVE-2022-50275","CVE-2022-50279","CVE-2022-50297","CVE-2022-50315","CVE-2022-50330","CVE-2022-50350","CVE-2022-50374","CVE-2022-50384","CVE-2022-50408","CVE-2022-50419","CVE-2023-53150","CVE-2023-53165","CVE-2023-53215","CVE-2023-53241","CVE-2023-53259","CVE-2023-53295","CVE-2023-53307","CVE-2023-53318","CVE-2023-53339","CVE-2023-53400","CVE-2023-53432","CVE-2023-53437","CVE-2023-53438","CVE-2025-38724","CVE-2025-39865","CVE-2025-39866","CVE-2025-39883"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2406"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50249"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50279"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50297"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50315"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50330"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50384"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50419"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53150"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53165"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53215"},{"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-53295"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53307"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53318"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53339"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53432"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53437"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53438"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38724"},{"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"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2510.1.0.0346.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","perf-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2510.1.0.0346.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","perf-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2510.1.0.0346.oe2003sp4.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-2406.json"}}],"schema_version":"1.7.3"}