{"schema_version":"1.7.2","id":"OESA-2024-1961","modified":"2024-08-09T11:08:46Z","published":"2024-08-09T11:08:46Z","upstream":["CVE-2022-48827","CVE-2023-52887","CVE-2024-38561","CVE-2024-38594","CVE-2024-38627","CVE-2024-39497","CVE-2024-40910","CVE-2024-40959","CVE-2024-40961","CVE-2024-40967","CVE-2024-40976","CVE-2024-40999","CVE-2024-41013","CVE-2024-41014","CVE-2024-41020","CVE-2024-41022","CVE-2024-41023","CVE-2024-41027","CVE-2024-41044","CVE-2024-41055","CVE-2024-41062","CVE-2024-41064","CVE-2024-41066","CVE-2024-41070","CVE-2024-41072","CVE-2024-41073","CVE-2024-41077","CVE-2024-41079","CVE-2024-41081","CVE-2024-41087","CVE-2024-41089","CVE-2024-41097","CVE-2024-42068","CVE-2024-42076","CVE-2024-42077","CVE-2024-42080","CVE-2024-42082","CVE-2024-42084","CVE-2024-42089","CVE-2024-42090","CVE-2024-42092","CVE-2024-42093","CVE-2024-42094","CVE-2024-42101","CVE-2024-42106","CVE-2024-42124","CVE-2024-42137","CVE-2024-42145","CVE-2024-42155","CVE-2024-42160","CVE-2024-42161","CVE-2024-42162","CVE-2024-42224"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix the behavior of READ near OFFSET_MAX\r\n\r\nDan Aloni reports:\n\u0026gt; Due to commit 8cfb9015280d (\u0026quot;NFS: Always provide aligned buffers to\n\u0026gt; the RPC read layers\u0026quot;) on the client, a read of 0xfff is aligned up\n\u0026gt; to server rsize of 0x1000.\n\u0026gt;\n\u0026gt; As a result, in a test where the server has a file of size\n\u0026gt; 0x7fffffffffffffff, and the client tries to read from the offset\n\u0026gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server\n\u0026gt; and it returns an NFS code of EINVAL to the client. The client as\n\u0026gt; a result indefinitely retries the request.\r\n\r\nThe Linux NFS client does not handle NFS?ERR_INVAL, even though all\nNFS specifications permit servers to return that status code for a\nREAD.\r\n\r\nInstead of NFS?ERR_INVAL, have out-of-range READ requests succeed\nand return a short result. Set the EOF flag in the result to prevent\nthe client from retrying the READ request. This behavior appears to\nbe consistent with Solaris NFS servers.\r\n\r\nNote that NFSv3 and NFSv4 use u64 offset values on the wire. These\nmust be converted to loff_t internally before use -- an implicit\ntype cast is not adequate for this purpose. Otherwise VFS checks\nagainst sb-\u0026gt;s_maxbytes do not work properly.(CVE-2022-48827)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new\r\n\r\nThis patch enhances error handling in scenarios with RTS (Request to\nSend) messages arriving closely. It replaces the less informative WARN_ON_ONCE\nbacktraces with a new error handling method. This provides clearer error\nmessages and allows for the early termination of problematic sessions.\nPreviously, sessions were only released at the end of j1939_xtp_rx_rts().\r\n\r\nPotentially this could be reproduced with something like:\ntestj1939 -r vcan0:0x80 \u0026amp;\nwhile true; do\n\t# send first RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send second RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send abort\n\tcansend vcan0 18EC8090#ff00000000002301;\ndone(CVE-2023-52887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkunit: Fix kthread reference\r\n\r\nThere is a race condition when a kthread finishes after the deadline and\nbefore the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: move the EST lock to struct stmmac_priv\r\n\r\nReinitialize the whole EST structure would also reset the mutex\nlock which is embedded in the EST structure, and then trigger\nthe following warning. To address this, move the lock to struct\nstmmac_priv. We also need to reacquire the mutex lock when doing\nthis initialization.\r\n\r\nDEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\nWARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068\n Modules linked in:\n CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29\n Hardware name: NXP i.MX8MPlus EVK board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __mutex_lock+0xd84/0x1068\n lr : __mutex_lock+0xd84/0x1068\n sp : ffffffc0864e3570\n x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003\n x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac\n x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff\n x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000\n x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8\n x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698\n x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001\n x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  __mutex_lock+0xd84/0x1068\n  mutex_lock_nested+0x28/0x34\n  tc_setup_taprio+0x118/0x68c\n  stmmac_setup_tc+0x50/0xf0\n  taprio_change+0x868/0xc9c(CVE-2024-38594)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstm class: Fix a double free in stm_register_device()\r\n\r\nThe put_device(\u0026amp;stm-\u0026gt;dev) call will trigger stm_device_release() which\nfrees \u0026quot;stm\u0026quot; so the vfree(stm) on the next line is a double free.(CVE-2024-38627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)\r\n\r\nLack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap\nallows users to call mmap with PROT_WRITE and MAP_PRIVATE flag\ncausing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:\nBUG_ON((vma-\u0026gt;vm_flags \u0026amp; VM_PFNMAP) \u0026amp;\u0026amp; is_cow_mapping(vma-\u0026gt;vm_flags));\r\n\r\nReturn -EINVAL early if COW mapping is detected.\r\n\r\nThis bug affects all drm drivers using default shmem helpers.\nIt can be reproduced by this simple example:\nvoid *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);\nptr[0] = 0;(CVE-2024-39497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix refcount imbalance on inbound connections\r\n\r\nWhen releasing a socket in ax25_release(), we call netdev_put() to\ndecrease the refcount on the associated ax.25 device. However, the\nexecution path for accepting an incoming connection never calls\nnetdev_hold(). This imbalance leads to refcount errors, and ultimately\nto kernel crashes.\r\n\r\nA typical call trace for the above situation will start with one of the\nfollowing errors:\r\n\r\n    refcount_t: decrement hit 0; leaking memory.\n    refcount_t: underflow; use-after-free.\r\n\r\nAnd will then have a trace like:\r\n\r\n    Call Trace:\n    \u0026lt;TASK\u0026gt;\n    ? show_regs+0x64/0x70\n    ? __warn+0x83/0x120\n    ? refcount_warn_saturate+0xb2/0x100\n    ? report_bug+0x158/0x190\n    ? prb_read_valid+0x20/0x30\n    ? handle_bug+0x3e/0x70\n    ? exc_invalid_op+0x1c/0x70\n    ? asm_exc_invalid_op+0x1f/0x30\n    ? refcount_warn_saturate+0xb2/0x100\n    ? refcount_warn_saturate+0xb2/0x100\n    ax25_release+0x2ad/0x360\n    __sock_release+0x35/0xa0\n    sock_close+0x19/0x20\n    [...]\r\n\r\nOn reboot (or any attempt to remove the interface), the kernel gets\nstuck in an infinite loop:\r\n\r\n    unregister_netdevice: waiting for ax0 to become free. Usage count = 0\r\n\r\nThis patch corrects these issues by ensuring that we call netdev_hold()\nand ax25_dev_hold() for new connections in ax25_accept(). This makes the\nlogic leading to ax25_accept() match the logic for ax25_bind(): in both\ncases we increment the refcount, which is ultimately decremented in\nax25_release().(CVE-2024-40910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\r\n\r\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\r\n\r\nsyzbot reported:\r\n\r\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 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL deref in fib6_nh_init()\r\n\r\nsyzbot reminds us that in6_dev_get() can return NULL.\r\n\r\nfib6_nh_init()\n    ip6_validate_gw(  \u0026amp;idev  )\n        ip6_route_check_nh(  idev  )\n            *idev = in6_dev_get(dev); // can be NULL\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606\nCode: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b\nRSP: 0018:ffffc900032775a0 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8\nRBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000\nR10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8\nR13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000\nFS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809\n  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853\n  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483\n  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579\n  sock_do_ioctl+0x158/0x460 net/socket.c:1222\n  sock_ioctl+0x629/0x8e0 net/socket.c:1341\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:907 [inline]\n  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f940f07cea9(CVE-2024-40961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: imx: Introduce timeout when waiting on transmitter empty\r\n\r\nBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potential\ndeadlock.\r\n\r\nIn case of the timeout, there is not much we can do, so we simply ignore\nthe transmitter state and optimistically try to continue.(CVE-2024-40967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: mask irqs in timeout path before hard reset\r\n\r\nThere is a race condition in which a rendering job might take just long\nenough to trigger the drm sched job timeout handler but also still\ncomplete before the hard reset is done by the timeout handler.\nThis runs into race conditions not expected by the timeout handler.\nIn some very specific cases it currently may result in a refcount\nimbalance on lima_pm_idle, with a stack dump such as:\r\n\r\n[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669628] Call trace:\n[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0\n[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0\n[10136.669656]  lima_gp_irq_handler+0xa8/0x120\n[10136.669666]  __handle_irq_event_percpu+0x48/0x160\n[10136.669679]  handle_irq_event+0x4c/0xc0\r\n\r\nWe can prevent that race condition entirely by masking the irqs at the\nbeginning of the timeout handler, at which point we give up on waiting\nfor that job entirely.\nThe irqs will be enabled again at the next hard reset which is already\ndone as a recovery by the timeout handler.(CVE-2024-40976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Add validation for completion descriptors consistency\r\n\r\nValidate that `first` flag is set only for the first\ndescriptor in multi-buffer packets.\nIn case of an invalid descriptor, a reset will occur.\nA new reset reason for RX data corruption has been added.(CVE-2024-40999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfs: don\u0026apos;t walk off the end of a directory data block\r\n\r\nThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry\nto make sure don\u0026apos;t stray beyond valid memory region. Before patching, the\nloop simply checks that the start offset of the dup and dep is within the\nrange. So in a crafted image, if last entry is xfs_dir2_data_unused, we\ncan change dup-\u0026gt;length to dup-\u0026gt;length-1 and leave 1 byte of space. In the\nnext traversal, this space will be considered as dup or dep. We may\nencounter an out of bound read when accessing the fixed members.\r\n\r\nIn the patch, we make sure that the remaining bytes large enough to hold\nan unused entry before accessing xfs_dir2_data_unused and\nxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make\nsure that the remaining bytes large enough to hold a dirent with a\nsingle-byte name before accessing xfs_dir2_data_entry.(CVE-2024-41013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfs: add bounds checking to xlog_recover_process_data\r\n\r\nThere is a lack of verification of the space occupied by fixed members\nof xlog_op_header in the xlog_recover_process_data.\r\n\r\nWe can create a crafted image to trigger an out of bounds read by\nfollowing these steps:\n    1) Mount an image of xfs, and do some file operations to leave records\n    2) Before umounting, copy the image for subsequent steps to simulate\n       abnormal exit. Because umount will ensure that tail_blk and\n       head_blk are the same, which will result in the inability to enter\n       xlog_recover_process_data\n    3) Write a tool to parse and modify the copied image in step 2\n    4) Make the end of the xlog_op_header entries only 1 byte away from\n       xlog_rec_header-\u0026gt;h_size\n    5) xlog_rec_header-\u0026gt;h_num_logops++\n    6) Modify xlog_rec_header-\u0026gt;h_crc\r\n\r\nFix:\nAdd a check to make sure there is sufficient space to access fixed members\nof xlog_op_header.(CVE-2024-41014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Fix fcntl/close race recovery compat path\r\n\r\nWhen I wrote commit 3cad1bc01041 (\u0026quot;filelock: Remove locks reliably when\nfcntl/close race is detected\u0026quot;), I missed that there are two copies of the\ncode I was patching: The normal version, and the version for 64-bit offsets\non 32-bit kernels.\nThanks to Greg KH for stumbling over this while doing the stable\nbackport...\r\n\r\nApply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()\r\n\r\nThe \u0026quot;instance\u0026quot; variable needs to be signed for the error handling to work.(CVE-2024-41022)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/deadline: Fix task_struct reference leak\r\n\r\nDuring the execution of the following stress test with linux-rt:\r\n\r\nstress-ng --cyclic 30 --timeout 30 --minimize --quiet\r\n\r\nkmemleak frequently reported a memory leak concerning the task_struct:\r\n\r\nunreferenced object 0xffff8881305b8000 (size 16136):\n  comm \u0026quot;stress-ng\u0026quot;, pid 614, jiffies 4294883961 (age 286.412s)\n  object hex dump (first 32 bytes):\n    02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  debug hex dump (first 16 bytes):\n    53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............\n  backtrace:\n    [\u0026lt;00000000046b6790\u0026gt;] dup_task_struct+0x30/0x540\n    [\u0026lt;00000000c5ca0f0b\u0026gt;] copy_process+0x3d9/0x50e0\n    [\u0026lt;00000000ced59777\u0026gt;] kernel_clone+0xb0/0x770\n    [\u0026lt;00000000a50befdc\u0026gt;] __do_sys_clone+0xb6/0xf0\n    [\u0026lt;000000001dbf2008\u0026gt;] do_syscall_64+0x5d/0xf0\n    [\u0026lt;00000000552900ff\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nThe issue occurs in start_dl_timer(), which increments the task_struct\nreference count and sets a timer. The timer callback, dl_task_timer,\nis supposed to decrement the reference count upon expiration. However,\nif enqueue_task_dl() is called before the timer expires and cancels it,\nthe reference count is not decremented, leading to the leak.\r\n\r\nThis patch fixes the reference leak by ensuring the task_struct\nreference count is properly decremented when the timer is canceled.(CVE-2024-41023)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nFix userfaultfd_api to return EINVAL as expected\r\n\r\nCurrently if we request a feature that is not set in the Kernel config we\nfail silently and return all the available features.  However, the man\npage indicates we should return an EINVAL.\r\n\r\nWe need to fix this issue since we can end up with a Kernel warning should\na program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with\nthe config not set with this feature.\r\n\r\n [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660\n [  200.820738] Modules linked in:\n [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8\n [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022\n [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660(CVE-2024-41027)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppp: reject claimed-as-LCP but actually malformed packets\r\n\r\nSince \u0026apos;ppp_async_encode()\u0026apos; assumes valid LCP packets (with code\nfrom 1 to 7 inclusive), add \u0026apos;ppp_check_packet()\u0026apos; to ensure that\nLCP packet has an actual body beyond PPP_LCP header bytes, and\nreject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: prevent derefencing NULL ptr in pfn_section_valid()\r\n\r\nCommit 5ec8e8ea8b77 (\u0026quot;mm/sparsemem: fix race in accessing\nmemory_section-\u0026gt;usage\u0026quot;) changed pfn_section_valid() to add a READ_ONCE()\ncall around \u0026quot;ms-\u0026gt;usage\u0026quot; to fix a race with section_deactivate() where\nms-\u0026gt;usage can be cleared.  The READ_ONCE() call, by itself, is not enough\nto prevent NULL pointer dereference.  We need to check its value before\ndereferencing it.(CVE-2024-41055)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbluetooth/l2cap: sync sock recv cb and release\r\n\r\nThe problem occurs between the system call to close the sock and hci_rx_work,\nwhere the former releases the sock and the latter accesses it without lock protection.\r\n\r\n           CPU0                       CPU1\n           ----                       ----\n           sock_close                 hci_rx_work\n\t   l2cap_sock_release         hci_acldata_packet\n\t   l2cap_sock_kill            l2cap_recv_frame\n\t   sk_free                    l2cap_conless_channel\n\t                              l2cap_sock_recv_cb\r\n\r\nIf hci_rx_work processes the data that needs to be received before the sock is\nclosed, then everything is normal; Otherwise, the work thread may access the\nreleased sock when receiving data.\r\n\r\nAdd a chan mutex in the rx callback of the sock to achieve synchronization between\nthe sock release and recv cb.\r\n\r\nSock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/eeh: avoid possible crash when edev-\u0026gt;pdev changes\r\n\r\nIf a PCI device is removed during eeh_pe_report_edev(), edev-\u0026gt;pdev\nwill change and can cause a crash, hold the PCI rescan/remove lock\nwhile taking a copy of edev-\u0026gt;pdev-\u0026gt;bus.(CVE-2024-41064)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nibmvnic: Add tx check to prevent skb leak\r\n\r\nBelow is a summary of how the driver stores a reference to an skb during\ntransmit:\n    tx_buff[free_map[consumer_index]]-\u0026gt;skb = new_skb;\n    free_map[consumer_index] = IBMVNIC_INVALID_MAP;\n    consumer_index ++;\nWhere variable data looks like this:\n    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]\n                                               \tconsumer_index^\n    tx_buff == [skb=null, skb=\u0026lt;ptr\u0026gt;, skb=\u0026lt;ptr\u0026gt;, skb=null, skb=null]\r\n\r\nThe driver has checks to ensure that free_map[consumer_index] pointed to\na valid index but there was no check to ensure that this index pointed\nto an unused/null skb address. So, if, by some chance, our free_map and\ntx_buff lists become out of sync then we were previously risking an\nskb memory leak. This could then cause tcp congestion control to stop\nsending packets, eventually leading to ETIMEDOUT.\r\n\r\nTherefore, add a conditional to ensure that the skb address is null. If\nnot then warn the user (because this is still a bug that should be\npatched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()\r\n\r\nAl reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().\r\n\r\nIt looks up `stt` from tablefd, but then continues to use it after doing\nfdput() on the returned fd. After the fdput() the tablefd is free to be\nclosed by another thread. The close calls kvm_spapr_tce_release() and\nthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.\r\n\r\nAlthough there are calls to rcu_read_lock() in\nkvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent\nthe UAF, because `stt` is used outside the locked regions.\r\n\r\nWith an artifcial delay after the fdput() and a userspace program which\ntriggers the race, KASAN detects the UAF:\r\n\r\n  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505\n  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1\n  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\n  Call Trace:\n    dump_stack_lvl+0xb4/0x108 (unreliable)\n    print_report+0x2b4/0x6ec\n    kasan_report+0x118/0x2b0\n    __asan_load4+0xb8/0xd0\n    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n    kvm_vfio_set_attr+0x524/0xac0 [kvm]\n    kvm_device_ioctl+0x144/0x240 [kvm]\n    sys_ioctl+0x62c/0x1810\n    system_call_exception+0x190/0x440\n    system_call_vectored_common+0x15c/0x2ec\n  ...\n  Freed by task 0:\n   ...\n   kfree+0xec/0x3e0\n   release_spapr_tce_table+0xd4/0x11c [kvm]\n   rcu_core+0x568/0x16a0\n   handle_softirqs+0x23c/0x920\n   do_softirq_own_stack+0x6c/0x90\n   do_softirq_own_stack+0x58/0x90\n   __irq_exit_rcu+0x218/0x2d0\n   irq_exit+0x30/0x80\n   arch_local_irq_restore+0x128/0x230\n   arch_local_irq_enable+0x1c/0x30\n   cpuidle_enter_state+0x134/0x5cc\n   cpuidle_enter+0x6c/0xb0\n   call_cpuidle+0x7c/0x100\n   do_idle+0x394/0x410\n   cpu_startup_entry+0x60/0x70\n   start_secondary+0x3fc/0x410\n   start_secondary_prolog+0x10/0x14\r\n\r\nFix it by delaying the fdput() until `stt` is no longer in use, which\nis effectively the entire function. To keep the patch minimal add a call\nto fdput() at each of the existing return paths. Future work can convert\nthe function to goto or __cleanup style cleanup.\r\n\r\nWith the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: wext: add extra SIOCSIWSCAN data check\r\n\r\nIn \u0026apos;cfg80211_wext_siwscan()\u0026apos;, add extra check whether number of\nchannels passed via \u0026apos;ioctl(sock, SIOCSIWSCAN, ...)\u0026apos; doesn\u0026apos;t exceed\nIW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme: avoid double free special payload\r\n\r\nIf a discard request needs to be retried, and that retry may fail before\na new special payload is added, a double free will result. Clear the\nRQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix validation of block size\r\n\r\nBlock size should be between 512 and PAGE_SIZE and be a power of 2. The current\ncheck does not validate this, so update the check.\r\n\r\nWithout this patch, null_blk would Oops due to a null pointer deref when\nloaded with bs=1536 [1].\r\n\r\n\n[axboe: remove unnecessary braces and != 0 check](CVE-2024-41077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: always initialize cqe.result\r\n\r\nThe spec doesn\u0026apos;t mandate that the first two double words (aka results)\nfor the command queue entry need to be set to 0 when they are not\nused (not specified). Though, the target implemention returns 0 for TCP\nand FC but not for RDMA.\r\n\r\nLet\u0026apos;s make RDMA behave the same and thus explicitly initializing the\nresult field. This prevents leaking any data from the stack.(CVE-2024-41079)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nila: block BH in ila_output()\r\n\r\nAs explained in commit 1378817486d6 (\u0026quot;tipc: block BH\nbefore using dst_cache\u0026quot;), net/core/dst_cache.c\nhelpers need to be called with BH disabled.\r\n\r\nila_output() is called from lwtunnel_output()\npossibly from process context, and under rcu_read_lock().\r\n\r\nWe might be interrupted by a softirq, re-enter ila_output()\nand corrupt dst_cache data structures.\r\n\r\nFix the race by using local_bh_disable().(CVE-2024-41081)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix double free on error\r\n\r\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\r\n\r\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.(CVE-2024-41087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes\r\n\r\nIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().\nAdd a check to avoid null pointer dereference.(CVE-2024-41089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: atm: cxacru: fix endpoint checking in cxacru_bind()\r\n\r\nSyzbot is still reporting quite an old issue [1] that occurs due to\nincomplete checking of present usb endpoints. As such, wrong\nendpoints types may be used at urb sumbitting stage which in turn\ntriggers a warning in usb_submit_urb().\r\n\r\nFix the issue by verifying that required endpoint types are present\nfor both in and out endpoints, taking into account cmd endpoint type.\r\n\r\nUnfortunately, this patch has not been tested on real hardware.\r\n\r\n[1] Syzbot report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\n...\nCall Trace:\n cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649\n cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760\n cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209\n usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055\n cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363\n usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:517 [inline]\n really_probe+0x23c/0xcd0 drivers/base/dd.c:595\n __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777\n __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894\n bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427\n __device_attach+0x228/0x4a0 drivers/base/dd.c:965\n bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487\n device_add+0xc2f/0x2180 drivers/base/core.c:3354\n usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()\r\n\r\nset_memory_ro() can fail, leaving memory unprotected.\r\n\r\nCheck its return and take it into account as an error.(CVE-2024-42068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: can: j1939: Initialize unused data in j1939_send_one()\r\n\r\nsyzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()\ncreates full frame including unused data, but it doesn\u0026apos;t initialize\nit. This causes the kernel-infoleak issue. Fix this by initializing\nunused data.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n copy_to_iter include/linux/uio.h:196 [inline]\n memcpy_to_msg include/linux/skbuff.h:4113 [inline]\n raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n ____sys_recvmsg+0x18a/0x620 net/socket.c:2803\n ___sys_recvmsg+0x223/0x840 net/socket.c:2845\n do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034\n x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1313 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n sock_alloc_send_skb include/net/sock.h:1842 [inline]\n j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]\n j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]\n j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nBytes 12-15 of 16 are uninitialized\nMemory access of size 16 starts at ffff888120969690\nData copied to user address 00000000200017c0\r\n\r\nCPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix DIO failure due to insufficient transaction credits\r\n\r\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits().  This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\r\n\r\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases.  For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents.  Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) \u0026lt;= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error.  This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\r\n\r\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\r\n\r\nHeming Zhao said:\r\n\r\n------\nPANIC: \u0026quot;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\u0026quot;\r\n\r\nPID: xxx  TASK: xxxx  CPU: 5  COMMAND: \u0026quot;SubmitThread-CA\u0026quot;\n  #0 machine_kexec at ffffffff8c069932\n  #1 __crash_kexec at ffffffff8c1338fa\n  #2 panic at ffffffff8c1d69b9\n  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/restrack: Fix potential invalid address access\r\n\r\nstruct rdma_restrack_entry\u0026apos;s kern_name was set to KBUILD_MODNAME\nin ib_create_cq(), while if the module exited but forgot del this\nrdma_restrack_entry, it would cause a invalid address access in\nrdma_restrack_clean() when print the owner of this rdma_restrack_entry.\r\n\r\nThese code is used to help find one forgotten PD release in one of the\nULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: Remove WARN() from __xdp_reg_mem_model()\r\n\r\nsyzkaller reports a warning in __xdp_reg_mem_model().\r\n\r\nThe warning occurs only if __mem_id_init_hash_table() returns an error. It\nreturns the error in two cases:\r\n\r\n  1. memory allocation fails;\n  2. rhashtable_init() fails when some fields of rhashtable_params\n     struct are not initialized properly.\r\n\r\nThe second case cannot happen since there is a static const rhashtable_params\nstruct with valid fields. So, warning is only triggered when there is a\nproblem with memory allocation.\r\n\r\nThus, there is no sense in using WARN() to handle this error and it can be\nsafely removed.\r\n\r\nWARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\r\n\r\nCPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\r\n\r\nCall Trace:\n xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344\n xdp_test_run_setup net/bpf/test_run.c:188 [inline]\n bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377\n bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267\n bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240\n __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649\n __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftruncate: pass a signed offset\r\n\r\nThe old ftruncate() syscall, using the 32-bit off_t misses a sign\nextension when called in compat mode on 64-bit architectures.  As a\nresult, passing a negative length accidentally succeeds in truncating\nto file size between 2GiB and 4GiB.\r\n\r\nChanging the type of the compat syscall to the signed compat_off_t\nchanges the behavior so it instead returns -EINVAL.\r\n\r\nThe native entry point, the truncate() syscall and the corresponding\nloff_t based variants are all correct already and do not suffer\nfrom this mistake.(CVE-2024-42084)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: fsl-asoc-card: set priv-\u0026gt;pdev before using it\r\n\r\npriv-\u0026gt;pdev pointer was set after being used in\nfsl_asoc_card_audmux_init().\nMove this assignment at the start of the probe function, so\nsub-functions can correctly use pdev through priv.\r\n\r\nfsl_asoc_card_audmux_init() dereferences priv-\u0026gt;pdev to get access to the\ndev struct, used with dev_err macros.\nAs priv is zero-initialised, there would be a NULL pointer dereference.\nNote that if priv-\u0026gt;dev is dereferenced before assignment but never used,\nfor example if there is no error to be printed, the driver won\u0026apos;t crash\nprobably due to compiler optimisations.(CVE-2024-42089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\r\n\r\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\r\n\r\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: davinci: Validate the obtained number of IRQs\r\n\r\nValue of pdata-\u0026gt;gpio_unbanked is taken from Device Tree. In case of broken\nDT due to any error this value can be any. Without this value validation\nthere can be out of chips-\u0026gt;irqs array boundaries access in\ndavinci_gpio_probe().\r\n\r\nValidate the obtained nirq value so that it won\u0026apos;t exceed the maximum\nnumber of IRQs per bank.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/dpaa2: Avoid explicit cpumask var allocation on stack\r\n\r\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\r\n\r\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\r\n\r\nUse *cpumask_var API(s) to address it.(CVE-2024-42093)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: Avoid explicit cpumask var allocation on stack\r\n\r\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\r\n\r\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\r\n\r\nUse *cpumask_var API(s) to address it.(CVE-2024-42094)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: fix null pointer dereference in nouveau_connector_get_modes\r\n\r\nIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet_diag: Initialize pad field in struct inet_diag_req_v2\r\n\r\nKMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw\nsockets uses the pad field in struct inet_diag_req_v2 for the\nunderlying protocol. This field corresponds to the sdiag_raw_protocol\nfield in struct inet_diag_req_raw.\r\n\r\ninet_diag_get_exact_compat() converts inet_diag_req to\ninet_diag_req_v2, but leaves the pad field uninitialized. So the issue\noccurs when raw_lookup() accesses the sdiag_raw_protocol field.\r\n\r\nFix this by initializing the pad field in\ninet_diag_get_exact_compat(). Also, do the same fix in\ninet_diag_dump_compat() to avoid the similar issue in the future.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]\nBUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_lookup net/ipv4/raw_diag.c:49 [inline]\n raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was stored to memory at:\n raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nLocal variable req.i created at:\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]\n inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\r\n\r\nCPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedf: Make qedf_execute_tmf() non-preemptible\r\n\r\nStop calling smp_processor_id() from preemptible code in\nqedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.\r\n\r\n[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646\n[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf](CVE-2024-42124)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot\r\n\r\nCommit 272970be3dab (\u0026quot;Bluetooth: hci_qca: Fix driver shutdown on closed\nserdev\u0026quot;) will cause below regression issue:\r\n\r\nBT can\u0026apos;t be enabled after below steps:\ncold boot -\u0026gt; enable BT -\u0026gt; disable BT -\u0026gt; warm reboot -\u0026gt; BT enable failure\nif property enable-gpios is not configured within DT|ACPI for QCA6390.\r\n\r\nThe commit is to fix a use-after-free issue within qca_serdev_shutdown()\nby adding condition to avoid the serdev is flushed or wrote after closed\nbut also introduces this regression issue regarding above steps since the\nVSC is not sent to reset controller during warm reboot.\r\n\r\nFixed by sending the VSC to reset controller within qca_serdev_shutdown()\nonce BT was ever enabled, and the use-after-free issue is also fixed by\nthis change since the serdev is still opened before it is flushed or wrote.\r\n\r\nVerified by the reported machine Dell XPS 13 9310 laptop over below two\nkernel commits:\ncommit e00fc2700a3f (\u0026quot;Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\u0026quot;) of bluetooth-next tree.\ncommit b23d98d46d28 (\u0026quot;Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\u0026quot;) of linus mainline tree.(CVE-2024-42137)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/core: Implement a limit on UMAD receive List\r\n\r\nThe existing behavior of ib_umad, which maintains received MAD\npackets in an unbounded list, poses a risk of uncontrolled growth.\nAs user-space applications extract packets from this list, the rate\nof extraction may not match the rate of incoming packets, leading\nto potential list overflow.\r\n\r\nTo address this, we introduce a limit to the size of the list. After\nconsidering typical scenarios, such as OpenSM processing, which can\nhandle approximately 100k packets per second, and the 1-second retry\ntimeout for most packets, we set the list size limit to 200k. Packets\nreceived beyond this limit are dropped, assuming they are likely timed\nout by the time they are handled by user-space.\r\n\r\nNotably, packets queued on the receive list due to reasons like\ntimed-out sends are preserved even when the list is full.(CVE-2024-42145)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of protected- and secure-keys\r\n\r\nAlthough the clear-key of neither protected- nor secure-keys is\naccessible, this key material should only be visible to the calling\nprocess. So wipe all copies of protected- or secure-keys from stack,\neven in case of an error.(CVE-2024-42155)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: check validation of fault attrs in f2fs_build_fault_attr()\r\n\r\n- It missed to check validation of fault attrs in parse_options(),\nlet\u0026apos;s fix to add check condition in f2fs_build_fault_attr().\n- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD\r\n\r\n[Changes from V1:\n - Use a default branch in the switch statement to initialize `val\u0026apos;.]\r\n\r\nGCC warns that `val\u0026apos; may be used uninitialized in the\nBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:\r\n\r\n\t[...]\n\tunsigned long long val;\t\t\t\t\t\t      \\\n\t[...]\t\t\t\t\t\t\t\t      \\\n\tswitch (__CORE_RELO(s, field, BYTE_SIZE)) {\t\t\t      \\\n\tcase 1: val = *(const unsigned char *)p; break;\t\t\t      \\\n\tcase 2: val = *(const unsigned short *)p; break;\t\t      \\\n\tcase 4: val = *(const unsigned int *)p; break;\t\t\t      \\\n\tcase 8: val = *(const unsigned long long *)p; break;\t\t      \\\n        }       \t\t\t\t\t\t\t      \\\n\t[...]\n\tval;\t\t\t\t\t\t\t\t      \\\n\t}\t\t\t\t\t\t\t\t      \\\r\n\r\nThis patch adds a default entry in the switch statement that sets\n`val\u0026apos; to zero in order to avoid the warning, and random values to be\nused in case __builtin_preserve_field_info returns unexpected values\nfor BPF_FIELD_BYTE_SIZE.\r\n\r\nTested in bpf-next master.\nNo regressions.(CVE-2024-42161)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngve: Account for stopped queues when reading NIC stats\r\n\r\nWe now account for the fact that the NIC might send us stats for a\nsubset of queues. Without this change, gve_get_ethtool_stats might make\nan invalid access on the priv-\u0026gt;stats_report-\u0026gt;stats array.(CVE-2024-42162)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: mv88e6xxx: Correct check for empty list\r\n\r\nSince commit a3c53be55c95 (\u0026quot;net: dsa: mv88e6xxx: Support multiple MDIO\nbusses\u0026quot;) mv88e6xxx_default_mdio_bus() has checked that the\nreturn value of list_first_entry() is non-NULL.\r\n\r\nThis appears to be intended to guard against the list chip-\u0026gt;mdios being\nempty.  However, it is not the correct check as the implementation of\nlist_first_entry is not designed to return NULL for empty lists.\r\n\r\nInstead, use list_first_entry_or_null() which does return NULL if the\nlist is empty.\r\n\r\nFlagged by Smatch.\nCompile tested only.(CVE-2024-42224)","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-222.0.0.121.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","perf-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-222.0.0.121.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","perf-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48827"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38561"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38594"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39497"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40910"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40959"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40967"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41013"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41022"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41027"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41044"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41055"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41070"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42068"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42080"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42082"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42092"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42093"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42101"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42106"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42124"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42137"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42145"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42161"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42162"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42224"}],"database_specific":{"severity":"High"}}