{"schema_version":"1.7.2","id":"OESA-2024-1995","modified":"2024-08-16T11:08:50Z","published":"2024-08-16T11:08:50Z","upstream":["CVE-2021-47582","CVE-2023-52888","CVE-2024-22386","CVE-2024-39509","CVE-2024-40942","CVE-2024-40990","CVE-2024-41012","CVE-2024-41034","CVE-2024-41035","CVE-2024-41042","CVE-2024-41046","CVE-2024-41065","CVE-2024-41078","CVE-2024-41092","CVE-2024-42087","CVE-2024-42095","CVE-2024-42096","CVE-2024-42098","CVE-2024-42105","CVE-2024-42114","CVE-2024-42126","CVE-2024-42128","CVE-2024-42143","CVE-2024-42148","CVE-2024-42154","CVE-2024-42156","CVE-2024-42157","CVE-2024-42158","CVE-2024-42223","CVE-2024-42225","CVE-2024-42229","CVE-2024-42244","CVE-2024-42246","CVE-2024-42247"],"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\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\r\n\r\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value.  If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \u0026quot;Task X blocked for more than N\nseconds\u0026quot;, as found in testing by syzbot:\r\n\r\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n      Not tainted 5.14.0-rc7-syzkaller #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:syz-executor.0  state:D stack:23192 pid: 8700 ppid:  8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\r\n\r\nTo fix this problem, this patch replaces usbfs\u0026apos;s calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Only free buffer VA that is not NULL\r\n\r\nIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly\ncalled only when the buffer to free exists, there are some instances\nthat didn\u0026apos;t do the check and triggered warnings in practice.\r\n\r\nWe believe those checks were forgotten unintentionally. Add the checks\nback to fix the warnings.(CVE-2023-52888)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\n(CVE-2024-22386)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: core: remove unnecessary WARN_ON() in implement()\r\n\r\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\r\n\r\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue \u0026amp;= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...(CVE-2024-39509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\r\n\r\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\r\n\r\nThis should take care of KASAN reports like this:\r\n\r\nunreferenced object 0xffff00000668d800 (size 128):\n  comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419552 (age 1836.444s)\n  hex dump (first 32 bytes):\n    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....\n    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....\u0026gt;...........\n  backtrace:\n    [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n    [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n    [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n    [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n    [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n    [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n    [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n    [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n    [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n    [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n    [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n    [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n    [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n    [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n  comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419553 (age 1836.440s)\n  hex dump (first 32 bytes):\n    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....\n    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6\u0026apos;.......Xy.....\n  backtrace:\n    [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n    [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n    [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n    [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n    [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n    [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n    [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n    [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n    [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n    [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n    [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n    [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n    [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n    [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-40942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/mlx5: Add check for srq max_sge attribute\r\n\r\nmax_sge attribute is passed by the user, and is inserted and used\nunchecked, so verify that the value doesn\u0026apos;t exceed maximum allowed value\nbefore using it.(CVE-2024-40990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix kernel bug on rename operation of broken directory\r\n\r\nSyzbot reported that in rename directory operation on broken directory on\nnilfs2, __block_write_begin_int() called to prepare block write may fail\nBUG_ON check for access exceeding the folio/page size.\r\n\r\nThis is because nilfs_dotdot(), which gets parent directory reference\nentry (\u0026quot;..\u0026quot;) of the directory to be moved or renamed, does not check\nconsistency enough, and may return location exceeding folio/page size for\nbroken directories.\r\n\r\nFix this issue by checking required directory entries (\u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;) in\nthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\r\n\r\nSyzbot has identified a bug in usbcore (see the Closes: tag below)\ncaused by our assumption that the reserved bits in an endpoint\ndescriptor\u0026apos;s bEndpointAddress field will always be 0.  As a result of\nthe bug, the endpoint_is_duplicate() routine in config.c (and possibly\nother routines as well) may believe that two descriptors are for\ndistinct endpoints, even though they have the same direction and\nendpoint number.  This can lead to confusion, including the bug\nidentified by syzbot (two descriptors with matching endpoint numbers\nand directions, where one was interrupt and the other was bulk).\r\n\r\nTo fix the bug, we will clear the reserved bits in bEndpointAddress\nwhen we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1\nspecs say these bits are \u0026quot;Reserved, reset to zero\u0026quot;.)  This requires us\nto make a copy of the descriptor earlier in usb_parse_endpoint() and\nuse the copy instead of the original when checking for duplicates.(CVE-2024-41035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: prefer nft_chain_validate\r\n\r\nnft_chain_validate already performs loop detection because a cycle will\nresult in a call stack overflow (ctx-\u0026gt;level \u0026gt;= NFT_JUMP_STACK_SIZE).\r\n\r\nIt also follows maps via -\u0026gt;validate callback in nft_lookup, so there\nappears no reason to iterate the maps again.\r\n\r\nnf_tables_check_loops() and all its helper functions can be removed.\nThis improves ruleset load time significantly, from 23s down to 12s.\r\n\r\nThis also fixes a crash bug. Old loop detection code can result in\nunbounded recursion:\r\n\r\nBUG: TASK stack guard page was hit at ....\nOops: stack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1\n[..]\r\n\r\nwith a suitable ruleset during validation of register stores.\r\n\r\nI can\u0026apos;t see any actual reason to attempt to check for this from\nnft_validate_register_store(), at this point the transaction is still in\nprogress, so we don\u0026apos;t have a full picture of the rule graph.\r\n\r\nFor nf-next it might make sense to either remove it or make this depend\non table-\u0026gt;validate_state in case we could catch an error earlier\n(for improved error reporting to userspace).(CVE-2024-41042)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: lantiq_etop: fix double free in detach\r\n\r\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.(CVE-2024-41046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\r\n\r\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\r\n\r\n    kernel BUG at mm/usercopy.c:102!\n    Oops: Exception in kernel mode, sig: 5 [#1]\n    LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n    Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n    scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n    CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n    Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n    NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n    REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)\n    MSR:  8000000000029033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt;  CR: 2828220f  XER: 0000000e\n    CFAR: c0000000001fdc80 IRQMASK: 0\n    [ ... GPRs omitted ... ]\n    NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n    LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n    Call Trace:\n     usercopy_abort+0x74/0xb0 (unreliable)\n     __check_heap_object+0xf8/0x120\n     check_heap_object+0x218/0x240\n     __check_object_size+0x84/0x1a4\n     dtl_file_read+0x17c/0x2c4\n     full_proxy_read+0x8c/0x110\n     vfs_read+0xdc/0x3a0\n     ksys_read+0x84/0x144\n     system_call_exception+0x124/0x330\n     system_call_vectored_common+0x15c/0x2ec\n    --- interrupt: 3000 at 0x7fff81f3ab34\r\n\r\nCommit 6d07d1cd300f (\u0026quot;usercopy: Restrict non-usercopy caches to size 0\u0026quot;)\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.(CVE-2024-41065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix quota root leak after quota disable failure\r\n\r\nIf during the quota disable we fail when cleaning the quota tree or when\ndeleting the root from the root tree, we jump to the \u0026apos;out\u0026apos; label without\never dropping the reference on the quota root, resulting in a leak of the\nroot since fs_info-\u0026gt;quota_root is no longer pointing to the root (we have\nset it to NULL just before those steps).\r\n\r\nFix this by always doing a btrfs_put_root() call under the \u0026apos;out\u0026apos; label.\nThis is a problem that exists since qgroups were first added in 2012 by\ncommit bed92eae26cc (\u0026quot;Btrfs: qgroup implementation and prototypes\u0026quot;), but\nback then we missed a kfree on the quota root and free_extent_buffer()\ncalls on its root and commit root nodes, since back then roots were not\nyet reference counted.(CVE-2024-41078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\r\n\r\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\r\n\r\n\u0026lt;6\u0026gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u0026lt;6\u0026gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u0026lt;6\u0026gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u0026lt;3\u0026gt; [414.070354] Unable to pin Y-tiled fence; err:-4\n\u0026lt;3\u0026gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active))\n...\n\u0026lt;4\u0026gt;[  609.603992] ------------[ cut here ]------------\n\u0026lt;2\u0026gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u0026lt;4\u0026gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;4\u0026gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u0026lt;4\u0026gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u0026lt;4\u0026gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u0026lt;4\u0026gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u0026lt;4\u0026gt;[  609.604271] Call Trace:\n\u0026lt;4\u0026gt;[  609.604273]  \u0026lt;TASK\u0026gt;\n...\n\u0026lt;4\u0026gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]\n\u0026lt;4\u0026gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]\n\u0026lt;4\u0026gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]\n\u0026lt;4\u0026gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]\n\u0026lt;4\u0026gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u0026lt;4\u0026gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u0026lt;4\u0026gt;[  609.605440]  process_scheduled_works+0x351/0x690\n...\r\n\r\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\r\n\r\nBefore commit 63baf4f3d587 (\u0026quot;drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\u0026quot;), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u0026gt;active via fence_update().   That commit introduced\nvma-\u0026gt;fence-\u0026gt;active in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u0026gt;active since only idleness of\nfence registers was needed.  But then, another commit 0d86ee35097a\n(\u0026quot;drm/i915/gt: Make fence revocation unequivocal\u0026quot;) replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u0026gt;fence-\u0026gt;active without first waiting on it.\r\n\r\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers.  Fix it by\nwaiting for idleness of vma-\u0026gt;fence-\u0026gt;active in i915_vma_revoke_fence().\r\n\r\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\r\n\r\nThe ilitek-ili9881c controls the reset GPIO using the non-sleeping\ngpiod_set_value() function. This complains loudly when the GPIO\ncontroller needs to sleep. As the caller can sleep, use\ngpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: 8250_omap: Implementation of Errata i2310\r\n\r\nAs per Errata i2310[0], Erroneous timeout can be triggered,\nif this Erroneous interrupt is not cleared then it may leads\nto storm of interrupts, therefore apply Errata i2310 solution.\r\n\r\n[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86: stop playing stack games in profile_pc()\r\n\r\nThe \u0026apos;profile_pc()\u0026apos; function is used for timer-based profiling, which\nisn\u0026apos;t really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren\u0026apos;t necessarily\nvalid.\r\n\r\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit\u0026apos;s not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\r\n\r\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases.  We\u0026apos;ve lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\r\n\r\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\r\n\r\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\r\n\r\n\tEflags always has bits 22 and up cleared unlike kernel addresses\r\n\r\nbut that basic stack layout assumption assumes that there isn\u0026apos;t any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\r\n\r\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\r\n\r\nWith no real practical reason for this any more, just remove the code.\r\n\r\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\r\n\r\n  0cb91a229364 (\u0026quot;i386: Account spinlocks to the caller during profiling for !FP kernels\u0026quot;)\n  31679f38d886 (\u0026quot;Simplify profile_pc on x86-64\u0026quot;)\r\n\r\nand a code unification from 2009:\r\n\r\n  ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\r\n\r\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: ecdh - explicitly zeroize private_key\r\n\r\nprivate_key is overwritten with the key parameter passed in by the\ncaller (if present), or alternatively a newly generated private key.\nHowever, it is possible that the caller provides a key (or the newly\ngenerated key) which is shorter than the previous key. In that\nscenario, some key material from the previous key would not be\noverwritten. The easiest solution is to explicitly zeroize the entire\nprivate_key array first.\r\n\r\nNote that this patch slightly changes the behavior of this function:\npreviously, if the ecc_gen_privkey failed, the old private_key would\nremain. Now, the private_key is always zeroized. This behavior is\nconsistent with the case where params.key is set and ecc_is_key_valid\nfails.(CVE-2024-42098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix inode number range checks\r\n\r\nPatch series \u0026quot;nilfs2: fix potential issues related to reserved inodes\u0026quot;.\r\n\r\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0026apos;s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value.  \r\n\r\n\nThis patch (of 3):\r\n\r\nIn the current implementation of nilfs2, \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot;, which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\r\n\r\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\r\n\r\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \u0026quot;ns_first_ino\u0026quot; is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\r\n\r\nFix these issues by checking the lower bound of \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot; and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\r\n\r\nAlso, change the type of \u0026quot;ns_first_ino\u0026quot; from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.(CVE-2024-42105)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\r\n\r\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\r\n\r\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\u0026quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\u0026quot;)\r\n\r\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last  enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last  enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last  enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u0026lt;ffff80008904166c\u0026gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n  __list_del include/linux/list.h:195 [inline]\n  __list_del_entry include/linux/list.h:218 [inline]\n  list_move_tail include/linux/list.h:310 [inline]\n  fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n  wake_tx_push_queue net/mac80211/util.c:294 [inline]\n  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n  xmit_one net/core/dev.c:3531 [inline]\n  dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n  dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n  neigh_output include/net/neighbour.h:542 [inline]\n  ip6_fini\n---truncated---(CVE-2024-42114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.\r\n\r\nnmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel\ncrash when invoked during real mode interrupt handling (e.g. early HMI/MCE\ninterrupt handler) if percpu allocation comes from vmalloc area.\r\n\r\nEarly HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()\nwrapper which invokes nmi_enter/nmi_exit calls. We don\u0026apos;t see any issue when\npercpu allocation is from the embedded first chunk. However with\nCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu\nallocation can come from the vmalloc area.\r\n\r\nWith kernel command line \u0026quot;percpu_alloc=page\u0026quot; we can force percpu allocation\nto come from vmalloc area and can see kernel crash in machine_check_early:\r\n\r\n[    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110\n[    1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0\n[    1.215719] --- interrupt: 200\n[    1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)\n[    1.215722] [c000000fffd731b0] [0000000000000000] 0x0\n[    1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8\r\n\r\nFix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu\nfirst chunk is not embedded.(CVE-2024-42126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: an30259a: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\norangefs: fix out-of-bounds fsid access\r\n\r\nArnd Bergmann sent a patch to fsdevel, he says:\r\n\r\n\u0026quot;orangefs_statfs() copies two consecutive fields of the superblock into\nthe statfs structure, which triggers a warning from the string fortification\nhelpers\u0026quot;\r\n\r\nJan Kara suggested an alternate way to do the patch to make it more readable.\r\n\r\nI ran both ideas through xfstests and both seem fine. This patch\nis based on Jan Kara\u0026apos;s suggestion.(CVE-2024-42143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\r\n\r\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\r\n\r\nCurrently there is a read/write out of bounds that occurs on the array\n\u0026quot;struct stats_query_entry query\u0026quot; present inside the \u0026quot;bnx2x_fw_stats_req\u0026quot;\nstruct in \u0026quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\u0026quot;.\nLooking at the definition of the \u0026quot;struct stats_query_entry query\u0026quot; array:\r\n\r\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n         BNX2X_FIRST_QUEUE_QUERY_IDX];\r\n\r\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \u0026quot;struct stats_query_entry query\u0026quot; are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\r\n\r\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\r\n\r\n/*\n  * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n  * control by the number of fast-path status blocks supported by the\n  * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n  * status block represents an independent interrupts context that can\n  * serve a regular L2 networking queue. However special L2 queues such\n  * as the FCoE queue do not require a FP-SB and other components like\n  * the CNIC may consume FP-SB reducing the number of possible L2 queues\n  *\n  * If the maximum number of FP-SB available is X then:\n  * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n  *    regular L2 queues is Y=X-1\n  * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n  * c. If the FCoE L2 queue is supported the actual number of L2 queues\n  *    is Y+1\n  * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n  *    slow-path interrupts) or Y+2 if CNIC is supported (one additional\n  *    FP interrupt context for the CNIC).\n  * e. The number of HW context (CID count) is always X or X+1 if FCoE\n  *    L2 queue is supported. The cid for the FCoE L2 queue is always X.\n  */\r\n\r\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\u0026quot;bnx2x: Add 57712 support\u0026quot;).\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \u0026quot;stats_query_entry query\u0026quot; was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\r\n\r\nThis patch increases the size of the \u0026quot;stats_query_entry query\u0026quot; array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\r\n\r\nStack traces:\r\n\r\nUBSAN: array-index-out-of-bounds in\n       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type \u0026apos;stats_query_entry [19]\u0026apos;\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t     #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---(CVE-2024-42148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_metrics: validate source addr length\r\n\r\nI don\u0026apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0026apos;t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).(CVE-2024-42154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of clear-key structures on failure\r\n\r\nWipe all sensitive data from stack for all IOCTLs, which convert a\nclear-key into a protected- or secure-key.(CVE-2024-42156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Use kfree_sensitive() to fix Coccinelle warnings\r\n\r\nReplace memzero_explicit() and kfree() with kfree_sensitive() to fix\nwarnings reported by Coccinelle:\r\n\r\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: tda10048: Fix integer overflow\r\n\r\nstate-\u0026gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\r\n\r\nCreate a new 64 bit variable to hold the calculations.(CVE-2024-42223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mt76: replace skb_put with skb_put_zero\r\n\r\nAvoid potentially reusing uninitialized data(CVE-2024-42225)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: aead,cipher - zeroize key buffer after use\r\n\r\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.(CVE-2024-42229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: serial: mos7840: fix crash on resume\r\n\r\nSince commit c49cfa917025 (\u0026quot;USB: serial: use generic method if no\nalternative is provided in usb serial layer\u0026quot;), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\r\n\r\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\r\n\r\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\r\n\r\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\r\n\r\n[ johan: analyse crash and rewrite commit message; set busy flag on\n         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\r\n\r\nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This\ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing\nthe kernel to potentially freeze up.\r\n\r\nNeil suggested:\r\n\r\n  This will propagate -EPERM up into other layers which might not be ready\n  to handle it. It might be safer to map EPERM to an error we would be more\n  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.\r\n\r\nECONNREFUSED as error seems reasonable. For programs setting a different error\ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels\nwhich do not have f10d05966196 (\u0026quot;bpf: Make BPF_PROG_RUN_ARRAY return -err\ninstead of allow boolean\u0026quot;), thus given that it is better to simply remap for\nconsistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: allowedips: avoid unaligned 64-bit memory accesses\r\n\r\nOn the parisc platform, the kernel issues kernel warnings because\nswap_endian() tries to load a 128-bit IPv6 address from an unaligned\nmemory location:\r\n\r\n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)\n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)\r\n\r\nAvoid such unaligned memory accesses by instead using the\nget_unaligned_be64() helper macro.\r\n\r\n[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-223.0.0.126.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-223.0.0.126.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47582"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-22386"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39509"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40990"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41012"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41042"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41046"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41092"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42096"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42105"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42126"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42128"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42143"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42154"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42158"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42223"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42225"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42244"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42246"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42247"}],"database_specific":{"severity":"High"}}