{"schema_version":"1.7.2","id":"OESA-2025-1096","modified":"2025-02-08T12:35:33Z","published":"2025-02-08T12:35:33Z","upstream":["CVE-2023-52434","CVE-2023-52480","CVE-2023-52614","CVE-2023-52627","CVE-2023-52913","CVE-2024-24857","CVE-2024-24859","CVE-2024-26659","CVE-2024-26664","CVE-2024-26673","CVE-2024-26747","CVE-2024-26748","CVE-2024-26749","CVE-2024-26753","CVE-2024-26781","CVE-2024-26790","CVE-2024-26793","CVE-2024-26952","CVE-2024-26954","CVE-2024-27004","CVE-2024-36479","CVE-2024-37021","CVE-2024-40965","CVE-2024-50194","CVE-2024-50280","CVE-2024-53131","CVE-2024-53183","CVE-2024-53198","CVE-2024-53201","CVE-2024-56539","CVE-2024-56571","CVE-2024-56588","CVE-2024-56610","CVE-2024-56611","CVE-2024-56623","CVE-2024-56688","CVE-2024-56704","CVE-2024-56715","CVE-2024-56746","CVE-2024-57892"],"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\nsmb: client: fix potential OOBs in smb2_parse_contexts()\n\nValidate offsets and lengths before dereferencing create contexts in\nsmb2_parse_contexts().\n\nThis fixes following oops when accessing invalid create contexts from\nserver:\n\n  BUG: unable to handle page fault for address: ffff8881178d8cc3\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 4a01067 P4D 4a01067 PUD 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n  RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]\n  Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00\n  00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 \u0026lt;0f\u0026gt; b7\n  7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00\n  RSP: 0018:ffffc900007939e0 EFLAGS: 00010216\n  RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90\n  RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000\n  RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000\n  R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000\n  R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22\n  FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)\n  knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0\n  PKRU: 55555554\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __die+0x23/0x70\n   ? page_fault_oops+0x181/0x480\n   ? search_module_extables+0x19/0x60\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? exc_page_fault+0x1b6/0x1c0\n   ? asm_exc_page_fault+0x26/0x30\n   ? smb2_parse_contexts+0xa0/0x3a0 [cifs]\n   SMB2_open+0x38d/0x5f0 [cifs]\n   ? smb2_is_path_accessible+0x138/0x260 [cifs]\n   smb2_is_path_accessible+0x138/0x260 [cifs]\n   cifs_is_path_remote+0x8d/0x230 [cifs]\n   cifs_mount+0x7e/0x350 [cifs]\n   cifs_smb3_do_mount+0x128/0x780 [cifs]\n   smb3_get_tree+0xd9/0x290 [cifs]\n   vfs_get_tree+0x2c/0x100\n   ? capable+0x37/0x70\n   path_mount+0x2d7/0xb80\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? _raw_spin_unlock_irqrestore+0x44/0x60\n   __x64_sys_mount+0x11a/0x150\n   do_syscall_64+0x47/0xf0\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n  RIP: 0033:0x7f8737657b1e(CVE-2023-52434)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A                        +  Thread B\n ksmbd_session_lookup            |  smb2_sess_setup\n   sess = xa_load                |\n                                 |\n                                 |    xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n                                 |\n                                 |    ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n                                 |\n   // UAF!                       |\n   sess-\u0026gt;last_active = jiffies   |\n                                 +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this.  And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n  mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829  if (request-\u0026gt;complete) {\n830          spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831          usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832                                    request);\n833          spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834  }\n835\n836  if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837      cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][  T150]\n[ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n  ...\n  cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n  list_del_init(\u0026amp;priv_req-\u0026gt;list);\n  ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][  T534]\n[ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4\n[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368\n[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n  virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n   WARNING: possible circular locking dependency detected\n   6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n   syz-executor.2/24141 is trying to acquire lock:\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n   but task is already holding lock:\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n   include/linux/spinlock.h:351 [inline]\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n   inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n   which lock already depends on the new lock.\n\n   the existing dependency chain (in reverse order) is:\n\n   -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n   _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n   spin_lock include/linux/spinlock.h:351 [inline]\n   __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n   inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n   __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n   inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n   rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n   rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n   ops_init+0x352/0x610 net/core/net_namespace.c:136\n   __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n   register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n   register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n   rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n   do_one_initcall+0x238/0x830 init/main.c:1236\n   do_initcall_level+0x157/0x210 init/main.c:1298\n   do_initcalls+0x3f/0x80 init/main.c:1314\n   kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n   kernel_init+0x1d/0x2a0 init/main.c:1441\n   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n   -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n   check_prev_add kernel/locking/lockdep.c:3134 [inline]\n   check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n   validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n   __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   lock_sock_fast include/net/sock.h:1723 [inline]\n   subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n   inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n   inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n   __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n   inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n   netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n   __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n   netlink_dump_start include/linux/netlink.h:338 [inline]\n   inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n   sock_diag_rcv_msg+0xe7/0x410\n   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n   sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n   netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n   netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n   netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n   sock_sendmsg_nosec net/socket.c:730 [inline]\n   __sock_sendmsg+0x221/0x270 net/socket.c:745\n   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n   ___sys_sendmsg net/socket.c:2638 [inline]\n   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n   do_syscall_64+0xf9/0x240\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985]  ? __die_body.cold+0x1a/0x1f\n[ 1010.715995]  ? die_addr+0x43/0x70\n[ 1010.716002]  ? exc_general_protection+0x199/0x2f0\n[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042]  __rtnl_newlink+0x1063/0x1700\n[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076]  ? __kernel_text_address+0x56/0xa0\n[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106]  ? stack_trace_save+0x91/0xd0\n[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139]  ? mark_held_locks+0x9e/0xe0\n[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160]  rtnl_newlink+0x69/0xa0\n[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179]  ? lock_acquire+0x1fe/0x560\n[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196]  netlink_rcv_skb+0x14d/0x440\n[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208]  ? netlink_ack+0xab0/0xab0\n[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233]  netlink_unicast+0x54b/0x800\n[ 1010.716240]  ? netlink_attachskb+0x870/0x870\n[ 1010.716248]  ? __check_object_size+0x2de/0x3b0\n[ 1010.716254]  netlink_sendmsg+0x938/0xe40\n[ 1010.716261]  ? netlink_unicast+0x800/0x800\n[ 1010.716269]  ? __import_iovec+0x292/0x510\n[ 1010.716276]  ? netlink_unicast+0x800/0x800\n[ 1010.716284]  __sock_sendmsg+0x159/0x190\n[ 1010.716290]  ____sys_sendmsg+0x712/0x880\n[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309]  ? lock_acquire+0x1fe/0x560\n[ 1010.716315]  ? drain_array_locked+0x90/0x90\n[ 1010.716324]  ___sys_sendmsg+0xf8/0x170\n[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337]  ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\n\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  rpm_resume+0xe0/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  clk_pm_runtime_get+0x30/0xb0\n  clk_disable_unused_subtree+0x58/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused+0x4c/0xe4\n  do_one_initcall+0xcc/0x2d8\n  do_initcall_level+0xa4/0x148\n  do_initcalls+0x5c/0x9c\n  do_basic_setup+0x24/0x30\n  kernel_init_freeable+0xec/0x164\n  kernel_init+0x28/0x120\n  ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  schedule_preempt_disabled+0x2c/0x48\n  __mutex_lock+0x238/0x488\n  __mutex_lock_slowpath+0x1c/0x28\n  mutex_lock+0x50/0x74\n  clk_prepare_lock+0x7c/0x9c\n  clk_core_prepare_lock+0x20/0x44\n  clk_prepare+0x24/0x30\n  clk_bulk_prepare+0x40/0xb0\n  mdss_runtime_resume+0x54/0x1c8\n  pm_generic_runtime_resume+0x30/0x44\n  __genpd_runtime_resume+0x68/0x7c\n  genpd_runtime_resume+0x108/0x1f4\n  __rpm_callback+0x84/0x144\n  rpm_callback+0x30/0x88\n  rpm_resume+0x1f4/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  __device_attach+0xe0/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  device_add+0x644/0x814\n  mipi_dsi_device_register_full+0xe4/0x170\n  devm_mipi_dsi_device_register_full+0x28/0x70\n  ti_sn_bridge_probe+0x1dc/0x2c0\n  auxiliary_bus_probe+0x4c/0x94\n  really_probe+0xcc/0x2c8\n  __driver_probe_device+0xa8/0x130\n  driver_probe_device+0x48/0x110\n  __device_attach_driver+0xa4/0xcc\n  bus_for_each_drv+0x8c/0xd8\n  __device_attach+0xf8/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  deferred_probe_work_func+0x9c/0xd8\n  process_one_work+0x148/0x518\n  worker_thread+0x138/0x350\n  kthread+0x138/0x1e0\n  ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n  safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n  instruction out-of-line when that instruction cannot be stepped\n  out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n  interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n  the compiler and sparse have no idea these contain a little-endian\n  32-bit value. The core uprobes code populates these with a memcpy()\n  which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n  to the similarly-named probe_opcode_t, which is an alias for u32.\n  Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n|         void *addr;\n|\n|         asm volatile(\n|         \u0026quot;       adrp    %x0, adrp_self\\n\u0026quot;\n|         \u0026quot;       add     %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n|         : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n|         void *ptr = adrp_self();\n|         bool equal = (ptr == adrp_self);\n|\n|         printf(\u0026quot;adrp_self   =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;%s\\n\u0026quot;,\n|                adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n|         return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n|   4007e0:       90000000        adrp    x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n|   4007e4:       911f8000        add     x0, x0, #0x7e0\n|   4007e8:       d65f03c0        ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure.  In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40  EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[  356.775250] ------------[ cut here ]------------\n[  356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n    ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n    [...]\n    memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n           user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[   20.830206] usb 1-1: Using ep0 maxpacket: 8\n[   20.833501] usb 1-1: config 0 descriptor??\n[   21.038518] usb 1-1: string descriptor 0 read error: -71\n[   21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[   21.042218] ------------[ cut here ]------------\n[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[   21.043195] Modules linked in:\n[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   21.044639] Workqueue: usb_hub_wq hub_event\n[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[   21.051136] PKRU: 55555554\n[   21.051331] Call Trace:\n[   21.051480]  \u0026lt;TASK\u0026gt;\n[   21.051611]  ? __warn+0xc4/0x210\n[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.052252]  ? report_bug+0x11b/0x1a0\n[   21.052540]  ? trace_hardirqs_on+0x31/0x40\n[   21.052901]  ? handle_bug+0x3d/0x70\n[   21.053197]  ? exc_invalid_op+0x1a/0x50\n[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20\n[   21.053924]  ? media_create_pad_link+0x91/0x2e0\n[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.054834]  ? media_create_pad_link+0x91/0x2e0\n[   21.055131]  ? _raw_spin_unlock+0x1e/0x40\n[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210\n[   21.055837]  uvc_mc_register_entities+0x358/0x400\n[   21.056144]  uvc_register_chains+0x1fd/0x290\n[   21.056413]  uvc_probe+0x380e/0x3dc0\n[   21.056676]  ? __lock_acquire+0x5aa/0x26e0\n[   21.056946]  ? find_held_lock+0x33/0xa0\n[   21.057196]  ? kernfs_activate+0x70/0x80\n[   21.057533]  ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855]   ESR = 0x0000000096000004\n[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125]   SET = 0, FnV = 0\n[67840.878291]   EA = 0, S1PTW = 0\n[67840.881545]   FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456]  down_write+0x30/0x98\n[67841.096017]  start_creating.part.0+0x60/0x198\n[67841.100613]  debugfs_create_dir+0x48/0x1f8\n[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115]  full_proxy_write+0x68/0xc8\n[67841.129175]  vfs_write+0xd8/0x3f0\n[67841.132708]  ksys_write+0x70/0x108\n[67841.136317]  __arm64_sys_write+0x24/0x38\n[67841.140440]  invoke_syscall+0x50/0x128\n[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273]  do_el0_svc+0x24/0x38\n[67841.152773]  el0_svc+0x38/0xd8\n[67841.156009]  el0t_64_sync_handler+0xc0/0xc8\n[67841.160361]  el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last  enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last  enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n|  \u0026lt;IRQ\u0026gt;\n|  dump_stack_lvl+0x7e/0xc0\n|  dump_stack+0x1d/0x30\n|  __might_resched+0x1a2/0x270\n|  rt_spin_lock+0x68/0x170\n|  kcsan_skip_report_debugfs+0x43/0xe0\n|  print_report+0xb5/0x590\n|  kcsan_report_known_origin+0x1b1/0x1d0\n|  kcsan_setup_watchpoint+0x348/0x650\n|  __tsan_unaligned_write1+0x16d/0x1d0\n|  hrtimer_interrupt+0x3d6/0x430\n|  __sysvec_apic_timer_interrupt+0xe8/0x3a0\n|  sysvec_apic_timer_interrupt+0x97/0xc0\n|  \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL.  So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022]  ? __dentry_kill+0x121/0x170\n[596663.813030]  ? _cond_resched+0x15/0x30\n[596663.813034]  ? _cond_resched+0x15/0x30\n[596663.813039]  ? wait_for_completion+0x35/0x190\n[596663.813048]  ? try_to_wake_up+0x63/0x540\n[596663.813055]  free_task+0x5a/0x60\n[596663.813061]  kthread_stop+0xf3/0x100\n[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota.  Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed.  Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-248.0.0.147.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-248.0.0.147.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1096"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52434"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52480"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52614"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52913"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-24857"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-24859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26664"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26747"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26749"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26790"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26793"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26954"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36479"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-37021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53183"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53198"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53201"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56539"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56571"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56610"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56623"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56688"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56715"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56746"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57892"}],"database_specific":{"severity":"High"}}