{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python3-perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.87.0.168.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.87.0.168.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nclk: sunxi-ng: Unregister clocks/resets when unbinding\r\n\r\nCurrently, unbinding a CCU driver unmaps the device\u0026apos;s MMIO region, while\nleaving its clocks/resets and their providers registered. This can cause\na page fault later when some clock operation tries to perform MMIO. Fix\nthis by separating the CCU initialization from the memory allocation,\nand then using a devres callback to unregister the clocks and resets.\r\n\r\nThis also fixes a memory leak of the `struct ccu_reset`, and uses the\ncorrect owner (the specific platform driver) for the clocks and resets.\r\n\r\nEarly OF clock providers are never unregistered, and limited error\nhandling is possible, so they are mostly unchanged. The error reporting\nis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR\r\n\r\nIn some case, the GDDV returns a package with a buffer which has\nzero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).\r\n\r\nThen the data_vault_read() got NULL point dereference problem when\naccessing the 0x10 value in data_vault.\r\n\r\n[   71.024560] BUG: kernel NULL pointer dereference, address:\n0000000000000010\r\n\r\nThis patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or\nNULL value in data_vault.(CVE-2022-48703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Avoid overwriting the copies of clcsock callback functions\r\n\r\nThe callback functions of clcsock will be saved and replaced during\nthe fallback. But if the fallback happens more than once, then the\ncopies of these callback functions will be overwritten incorrectly,\nresulting in a loop call issue:\r\n\r\nclcsk-\u0026gt;sk_error_report\n |- smc_fback_error_report() \u0026lt;------------------------------|\n     |- smc_fback_forward_wakeup()                          | (loop)\n         |- clcsock_callback()  (incorrectly overwritten)   |\n             |- smc-\u0026gt;clcsk_error_report() ------------------|\r\n\r\nSo this patch fixes the issue by saving these function pointers only\nonce in the fallback and avoiding overwriting.(CVE-2022-48780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr\r\n\r\nThis node pointer is returned by of_find_compatible_node() with\nrefcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: Fix double free in of_parse_phandle_with_args_map\r\n\r\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of \u0026quot;new\u0026quot; is\nNULL on the first iteration of the inner loop.\r\n\r\nMake sure that this is true in all iterations of the outer\nloop by setting \u0026quot;new\u0026quot; to NULL after its value is assigned to \u0026quot;cur\u0026quot;.\r\n\r\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.(CVE-2023-52679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: do not free live element\r\n\r\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern.  Quoting Pablo:\r\n\r\n  add_elem(\u0026quot;00000000\u0026quot;) timeout 100 ms\n  ...\n  add_elem(\u0026quot;0000000X\u0026quot;) timeout 100 ms\n  del_elem(\u0026quot;0000000X\u0026quot;) \u0026lt;---------------- delete one that was just added\n  ...\n  add_elem(\u0026quot;00005000\u0026quot;) timeout 100 ms\r\n\r\n  1) nft_pipapo_remove() removes element 0000000X\n  Then, KASAN shows a splat.\r\n\r\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\r\n\r\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\r\n\r\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\r\n\r\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\r\n\r\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\r\n\r\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\r\n\r\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\r\n\r\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\r\n\r\nv2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: release mutex after nft_gc_seq_end from abort path\r\n\r\nThe commit mutex should not be released during the critical section\nbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC\nworker could collect expired objects and get the released commit lock\nwithin the same GC sequence.\r\n\r\nnf_tables_module_autoload() temporarily releases the mutex to load\nmodule dependencies, then it goes back to replay the transaction again.\nMove it at the end of the abort phase after nft_gc_seq_end() is called.(CVE-2024-26925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[   82.890906]\n[   82.890906] ============================================\n[   82.890906] WARNING: possible recursive locking detected\n[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W\n[   82.890906] --------------------------------------------\n[   82.890906] ping/418 is trying to acquire lock:\n[   82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] but task is already holding lock:\n[   82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] other info that might help us debug this:\n[   82.890906]  Possible unsafe locking scenario:\n[   82.890906]\n[   82.890906]        CPU0\n[   82.890906]        ----\n[   82.890906]   lock(\u0026amp;sch-\u0026gt;q.lock);\n[   82.890906]   lock(\u0026amp;sch-\u0026gt;q.lock);\n[   82.890906]\n[   82.890906]  *** DEADLOCK ***\n[   82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\r\n\r\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\r\n\r\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\r\n\r\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mvpp2: clear BM pool before initialization\r\n\r\nRegister value persist after booting the kernel using\nkexec which results in kernel panic. Thus clear the\nBM pool registers before initialisation to fix the issue.(CVE-2024-35837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: flush pending destroy work before exit_net release\r\n\r\nSimilar to 2c9f0293280e (\u0026quot;netfilter: nf_tables: flush pending destroy\nwork before netlink notifier\u0026quot;) to address a race between exit_net and\nthe destroy workqueue.\r\n\r\nThe trace below shows an element to be released via destroy workqueue\nwhile exit_net path (triggered via module removal) has already released\nthe set that is used in such transaction.\r\n\r\n[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465\n[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359\n[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]\n[ 1360.547984] Call Trace:\n[ 1360.547991]  \u0026lt;TASK\u0026gt;\n[ 1360.547998]  dump_stack_lvl+0x53/0x70\n[ 1360.548014]  print_report+0xc4/0x610\n[ 1360.548026]  ? __virt_addr_valid+0xba/0x160\n[ 1360.548040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 1360.548054]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548176]  kasan_report+0xae/0xe0\n[ 1360.548189]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548312]  nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548447]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]\n[ 1360.548577]  ? _raw_spin_unlock_irq+0x18/0x30\n[ 1360.548591]  process_one_work+0x2f1/0x670\n[ 1360.548610]  worker_thread+0x4d3/0x760\n[ 1360.548627]  ? __pfx_worker_thread+0x10/0x10\n[ 1360.548640]  kthread+0x16b/0x1b0\n[ 1360.548653]  ? __pfx_kthread+0x10/0x10\n[ 1360.548665]  ret_from_fork+0x2f/0x50\n[ 1360.548679]  ? __pfx_kthread+0x10/0x10\n[ 1360.548690]  ret_from_fork_asm+0x1a/0x30\n[ 1360.548707]  \u0026lt;/TASK\u0026gt;\r\n\r\n[ 1360.548719] Allocated by task 192061:\n[ 1360.548726]  kasan_save_stack+0x20/0x40\n[ 1360.548739]  kasan_save_track+0x14/0x30\n[ 1360.548750]  __kasan_kmalloc+0x8f/0xa0\n[ 1360.548760]  __kmalloc_node+0x1f1/0x450\n[ 1360.548771]  nf_tables_newset+0x10c7/0x1b50 [nf_tables]\n[ 1360.548883]  nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]\n[ 1360.548909]  nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]\n[ 1360.548927]  netlink_unicast+0x367/0x4f0\n[ 1360.548935]  netlink_sendmsg+0x34b/0x610\n[ 1360.548944]  ____sys_sendmsg+0x4d4/0x510\n[ 1360.548953]  ___sys_sendmsg+0xc9/0x120\n[ 1360.548961]  __sys_sendmsg+0xbe/0x140\n[ 1360.548971]  do_syscall_64+0x55/0x120\n[ 1360.548982]  entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n[ 1360.548994] Freed by task 192222:\n[ 1360.548999]  kasan_save_stack+0x20/0x40\n[ 1360.549009]  kasan_save_track+0x14/0x30\n[ 1360.549019]  kasan_save_free_info+0x3b/0x60\n[ 1360.549028]  poison_slab_object+0x100/0x180\n[ 1360.549036]  __kasan_slab_free+0x14/0x30\n[ 1360.549042]  kfree+0xb6/0x260\n[ 1360.549049]  __nft_release_table+0x473/0x6a0 [nf_tables]\n[ 1360.549131]  nf_tables_exit_net+0x170/0x240 [nf_tables]\n[ 1360.549221]  ops_exit_list+0x50/0xa0\n[ 1360.549229]  free_exit_list+0x101/0x140\n[ 1360.549236]  unregister_pernet_operations+0x107/0x160\n[ 1360.549245]  unregister_pernet_subsys+0x1c/0x30\n[ 1360.549254]  nf_tables_module_exit+0x43/0x80 [nf_tables]\n[ 1360.549345]  __do_sys_delete_module+0x253/0x370\n[ 1360.549352]  do_syscall_64+0x55/0x120\n[ 1360.549360]  entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n(gdb) list *__nft_release_table+0x473\n0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).\n11349           list_for_each_entry_safe(flowtable, nf, \u0026amp;table-\u0026gt;flowtables, list) {\n11350                   list_del(\u0026amp;flowtable-\u0026gt;list);\n11351                   nft_use_dec(\u0026amp;table-\u0026gt;use);\n11352                   nf_tables_flowtable_destroy(flowtable);\n11353           }\n11354           list_for_each_entry_safe(set, ns, \u0026amp;table-\u0026gt;sets, list) {\n11355                   list_del(\u0026amp;set-\u0026gt;list);\n11356                   nft_use_dec(\u0026amp;table-\u0026gt;use);\n11357                   if (set-\u0026gt;flags \u0026amp; (NFT_SET_MAP | NFT_SET_OBJECT))\n11358                           nft_map_deactivat\n---truncated---(CVE-2024-35899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Skip do PCI error slot reset during RAS recovery\r\n\r\nWhy:\n    The PCI error slot reset maybe triggered after inject ue to UMC multi times, this\n    caused system hang.\n    [  557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume\n    [  557.373718] [drm] PCIE GART of 512M enabled.\n    [  557.373722] [drm] PTB located at 0x0000031FED700000\n    [  557.373788] [drm] VRAM is lost due to GPU reset!\n    [  557.373789] [drm] PSP is resuming...\n    [  557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset\n    [  557.547067] [drm] PCI error: detected callback, state(1)!!\n    [  557.547069] [drm] No support for XGMI hive yet...\n    [  557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter\n    [  557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations\n    [  557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered\n    [  557.610492] [drm] PCI error: slot reset callback!!\n    ...\n    [  560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!\n    [  560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!\n    [  560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI\n    [  560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G           OE     5.15.0-91-generic #101-Ubuntu\n    [  560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023\n    [  560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]\n    [  560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n    [  560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff \u0026lt;48\u0026gt; 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00\n    [  560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202\n    [  560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0\n    [  560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010\n    [  560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08\n    [  560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000\n    [  560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000\n    [  560.803889] FS:  0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000\n    [  560.812973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    [  560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0\n    [  560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    [  560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n    [  560.843444] PKRU: 55555554\n    [  560.846480] Call Trace:\n    [  560.849225]  \u0026lt;TASK\u0026gt;\n    [  560.851580]  ? show_trace_log_lvl+0x1d6/0x2ea\n    [  560.856488]  ? show_trace_log_lvl+0x1d6/0x2ea\n    [  560.861379]  ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n    [  560.867778]  ? show_regs.part.0+0x23/0x29\n    [  560.872293]  ? __die_body.cold+0x8/0xd\n    [  560.876502]  ? die_addr+0x3e/0x60\n    [  560.880238]  ? exc_general_protection+0x1c5/0x410\n    [  560.885532]  ? asm_exc_general_protection+0x27/0x30\n    [  560.891025]  ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n    [  560.898323]  amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n    [  560.904520]  process_one_work+0x228/0x3d0\nHow:\n    In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected\n    all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: fix uninitialized values during inode evict\r\n\r\nIf an iget fails due to not being able to retrieve information\nfrom the server then the inode structure is only partially\ninitialized.  When the inode gets evicted, references to\nuninitialized structures (like fscache cookies) were being\nmade.\r\n\r\nThis patch checks for a bad_inode before doing anything other\nthan clearing the inode from the cache.  Since the inode is\nbad, it shouldn\u0026apos;t have any state associated with it that needs\nto be written back (and there really isn\u0026apos;t a way to complete\nthose anyways).(CVE-2024-36923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: bridge: cdns-mhdp8546: Fix possible null pointer dereference\r\n\r\nIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is\nassigned to mhdp_state-\u0026gt;current_mode, and there is a dereference of it in\ndrm_mode_set_name(), which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate().\r\n\r\nFix this bug add a check of mhdp_state-\u0026gt;current_mode.(CVE-2024-38548)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: add a proper sanity check for endpoints\r\n\r\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\r\n\r\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\r\n\r\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\r\n\r\n[2] Related syzkaller crashes:(CVE-2024-38567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\r\n\r\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\r\n\r\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\r\n\r\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n   MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: davinci: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u0026gt;\ndavinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\r\n\r\nIn lio_vf_rep_copy_packet() pg_info-\u0026gt;page is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\r\n\r\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t  octeon_droq_dispatch_pkt\n\t   octeon_create_recv_info\n\t    ...search in the dispatch_list...\n\t     -\u0026gt;disp_fn(rdisp-\u0026gt;rinfo, ...)\n\t      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u0026gt;page to NULL.\nSo this check looks unneeded and doesn\u0026apos;t solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can\u0026apos;t do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\r\n\r\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/io-wq: Use set_bit() and test_bit() at worker-\u0026gt;flags\r\n\r\nUtilize set_bit() and test_bit() on worker-\u0026gt;flags within io_uring/io-wq\nto address potential data races.\r\n\r\nThe structure io_worker-\u0026gt;flags may be accessed through various data\npaths, leading to concurrency issues. When KCSAN is enabled, it reveals\ndata races occurring in io_worker_handle_work and\nio_wq_activate_free_worker functions.\r\n\r\n\t BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker\n\t write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:\n\t io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)\n\t io_wq_worker (io_uring/io-wq.c:?)\n\u0026lt;snip\u0026gt;\r\n\r\n\t read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:\n\t io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)\n\t io_wq_enqueue (io_uring/io-wq.c:947)\n\t io_queue_iowq (io_uring/io_uring.c:524)\n\t io_req_task_submit (io_uring/io_uring.c:1511)\n\t io_handle_tw_list (io_uring/io_uring.c:1198)\n\u0026lt;snip\u0026gt;\r\n\r\nLine numbers against commit 18daea77cca6 (\u0026quot;Merge tag \u0026apos;for-linus\u0026apos; of\ngit://git.kernel.org/pub/scm/virt/kvm/kvm\u0026quot;).\r\n\r\nThese races involve writes and reads to the same memory location by\ndifferent tasks running on different CPUs. To mitigate this, refactor\nthe code to use atomic operations such as set_bit(), test_bit(), and\nclear_bit() instead of basic \u0026quot;and\u0026quot; and \u0026quot;or\u0026quot; operations. This ensures\nthread-safe manipulation of worker flags.\r\n\r\nAlso, move `create_index` to avoid holes in the structure.(CVE-2024-39508)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\r\n\r\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\r\n\r\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm\u0026apos;s semaphore, and this operation may sleep. This is\nproblematic, because  __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[\u0026lt;ffffffff800060dc\u0026gt;] dump_backtrace+0x1c/0x24\n[\u0026lt;ffffffff8091ef6e\u0026gt;] show_stack+0x2c/0x38\n[\u0026lt;ffffffff8092baf8\u0026gt;] dump_stack_lvl+0x5a/0x72\n[\u0026lt;ffffffff8092bb24\u0026gt;] dump_stack+0x14/0x1c\n[\u0026lt;ffffffff8003b7ac\u0026gt;] __might_resched+0x104/0x10e\n[\u0026lt;ffffffff8003b7f4\u0026gt;] __might_sleep+0x3e/0x62\n[\u0026lt;ffffffff8093276a\u0026gt;] down_write+0x20/0x72\n[\u0026lt;ffffffff8000cf00\u0026gt;] __set_memory+0x82/0x2fa\n[\u0026lt;ffffffff8000d324\u0026gt;] __kernel_map_pages+0x5a/0xd4\n[\u0026lt;ffffffff80196cca\u0026gt;] __alloc_pages_bulk+0x3b2/0x43a\n[\u0026lt;ffffffff8018ee82\u0026gt;] __vmalloc_node_range+0x196/0x6ba\n[\u0026lt;ffffffff80011904\u0026gt;] copy_process+0x72c/0x17ec\n[\u0026lt;ffffffff80012ab4\u0026gt;] kernel_clone+0x60/0x2fe\n[\u0026lt;ffffffff80012f62\u0026gt;] kernel_thread+0x82/0xa0\n[\u0026lt;ffffffff8003552c\u0026gt;] kthreadd+0x14a/0x1be\n[\u0026lt;ffffffff809357de\u0026gt;] ret_from_fork+0xe/0x1c\r\n\r\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.(CVE-2024-40915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Avoid blocking in RCU read-side critical section\r\n\r\nA panic happens in ima_match_policy:\r\n\r\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\nPGD 42f873067 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 5 PID: 1286325 Comm: kubeletmonit.sh\nKdump: loaded Tainted: P\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n               BIOS 0.0.0 02/06/2015\nRIP: 0010:ima_match_policy+0x84/0x450\nCode: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39\n      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d\n      f2 b9 f4 00 0f 84 9c 01 00 00 \u0026lt;44\u0026gt; 85 73 10 74 ea\n      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f\nRSP: 0018:ff71570009e07a80 EFLAGS: 00010207\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200\nRDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000\nRBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739\nR10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970\nR13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001\nFS:  00007f5195b51740(0000)\nGS:ff3e278b12d40000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ima_get_action+0x22/0x30\n process_measurement+0xb0/0x830\n ? page_add_file_rmap+0x15/0x170\n ? alloc_set_pte+0x269/0x4c0\n ? prep_new_page+0x81/0x140\n ? simple_xattr_get+0x75/0xa0\n ? selinux_file_open+0x9d/0xf0\n ima_file_check+0x64/0x90\n path_openat+0x571/0x1720\n do_filp_open+0x9b/0x110\n ? page_counter_try_charge+0x57/0xc0\n ? files_cgroup_alloc_fd+0x38/0x60\n ? __alloc_fd+0xd4/0x250\n ? do_sys_open+0x1bd/0x250\n do_sys_open+0x1bd/0x250\n do_syscall_64+0x5d/0x1d0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nCommit c7423dbdbc9e (\u0026quot;ima: Handle -ESTALE returned by\nima_filter_rule_match()\u0026quot;) introduced call to ima_lsm_copy_rule within a\nRCU read-side critical section which contains kmalloc with GFP_KERNEL.\nThis implies a possible sleep and violates limitations of RCU read-side\ncritical sections on non-PREEMPT systems.\r\n\r\nSleeping within RCU read-side critical section might cause\nsynchronize_rcu() returning early and break RCU protection, allowing a\nUAF to happen.\r\n\r\nThe root cause of this issue could be described as follows:\n|\tThread A\t|\tThread B\t|\n|\t\t\t|ima_match_policy\t|\n|\t\t\t|  rcu_read_lock\t|\n|ima_lsm_update_rule\t|\t\t\t|\n|  synchronize_rcu\t|\t\t\t|\n|\t\t\t|    kmalloc(GFP_KERNEL)|\n|\t\t\t|      sleep\t\t|\n==\u0026gt; synchronize_rcu returns early\n|  kfree(entry)\t\t|\t\t\t|\n|\t\t\t|    entry = entry-\u0026gt;next|\n==\u0026gt; UAF happens and entry now becomes NULL (or could be anything).\n|\t\t\t|    entry-\u0026gt;action\t|\n==\u0026gt; Accessing entry might cause panic.\r\n\r\nTo fix this issue, we are converting all kmalloc that is called within\nRCU read-side critical section to use GFP_ATOMIC.\r\n\r\n[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list\r\n\r\nUse list_for_each_entry_safe() to allow iterating through the list and\ndeleting the entry in the iteration process. The descriptor is freed via\nidxd_desc_complete() and there\u0026apos;s a slight chance may cause issue for\nthe list iterator when the descriptor is reused by another thread\nwithout it being deleted from the list.(CVE-2024-40956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL dereference in rt6_probe()\r\n\r\nsyzbot caught a NULL dereference in rt6_probe() [1]\r\n\r\nBail out if  __in6_dev_get() returns NULL.\r\n\r\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n  find_rr_leaf net/ipv6/route.c:853 [inline]\n  rt6_select net/ipv6/route.c:897 [inline]\n  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n  pol_lookup_func include/net/ip6_fib.h:616 [inline]\n  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x6b6/0x1140 fs/read_write.c:590\n  ksys_write+0x1f8/0x260 fs/read_write.c:643\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)\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\next4: do not create EA inode under buffer lock\r\n\r\next4_xattr_set_entry() creates new EA inodes while holding buffer lock\non the external xattr block. This is problematic as it nests all the\nallocation locking (which acquires locks on other buffers) under the\nbuffer lock. This can even deadlock when the filesystem is corrupted and\ne.g. quota file is setup to contain xattr block as data block. Move the\nallocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrop_monitor: replace spin_lock by raw_spin_lock\r\n\r\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026amp;data-\u0026gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last  enabled at (139908): [\u0026lt;ffffffffb1df2b33\u0026gt;] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u0026lt;ffffffffb19bd03d\u0026gt;] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last  enabled at (139892): [\u0026lt;ffffffffb07a1083\u0026gt;] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u0026lt;ffffffffb0909b33\u0026gt;] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u0026lt;ffffffffb1de786b\u0026gt;] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\r\n\r\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\r\n\r\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.(CVE-2024-40980)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last  enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n  spin_unlock_bh include/linux/spinlock.h:396 [inline]\n  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n  process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n  process_scheduled_works kernel/workqueue.c:2706 [inline]\n  worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n  kthread+0x288/0x310 kernel/kthread.c:388\n  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\r\n\r\nsyzbot found hanging tasks waiting on rtnl_lock [1]\r\n\r\nA reproducer is available in the syzbot bug.\r\n\r\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\r\n\r\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\r\n\r\n[1]\r\n\r\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u0026lt;TASK\u0026gt;\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: don\u0026apos;t allow mapping the MMIO HDP page with large pages\r\n\r\nWe don\u0026apos;t get the right offset in that case.  The GPU has\nan unused 4K area of the register BAR space into which you can\nremap registers.  We remap the HDP flush registers into this\nspace to allow userspace (CPU or GPU) to flush the HDP when it\nupdates VRAM.  However, on systems with \u0026gt;4K pages, we end up\nexposing PAGE_SIZE of MMIO space.(CVE-2024-41011)",
  "id": "OESA-2024-1941",
  "modified": "2026-08-06T11:07:24Z",
  "published": "2024-08-02T11:07:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1941"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26925"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35837"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36923"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38548"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40945"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40967"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41011"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47205",
    "CVE-2022-48703",
    "CVE-2022-48780",
    "CVE-2022-48859",
    "CVE-2023-52679",
    "CVE-2024-26924",
    "CVE-2024-26925",
    "CVE-2024-27010",
    "CVE-2024-34777",
    "CVE-2024-35808",
    "CVE-2024-35837",
    "CVE-2024-35899",
    "CVE-2024-35931",
    "CVE-2024-36923",
    "CVE-2024-37078",
    "CVE-2024-38548",
    "CVE-2024-38567",
    "CVE-2024-38607",
    "CVE-2024-38611",
    "CVE-2024-38621",
    "CVE-2024-39475",
    "CVE-2024-39476",
    "CVE-2024-39484",
    "CVE-2024-39506",
    "CVE-2024-39508",
    "CVE-2024-40915",
    "CVE-2024-40945",
    "CVE-2024-40947",
    "CVE-2024-40956",
    "CVE-2024-40960",
    "CVE-2024-40967",
    "CVE-2024-40972",
    "CVE-2024-40980",
    "CVE-2024-40981",
    "CVE-2024-40995",
    "CVE-2024-41011"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-221.0.0.124.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-tools-devel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-221.0.0.124.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nclk: sunxi-ng: Unregister clocks/resets when unbinding\r\n\r\nCurrently, unbinding a CCU driver unmaps the device\u0026apos;s MMIO region, while\nleaving its clocks/resets and their providers registered. This can cause\na page fault later when some clock operation tries to perform MMIO. Fix\nthis by separating the CCU initialization from the memory allocation,\nand then using a devres callback to unregister the clocks and resets.\r\n\r\nThis also fixes a memory leak of the `struct ccu_reset`, and uses the\ncorrect owner (the specific platform driver) for the clocks and resets.\r\n\r\nEarly OF clock providers are never unregistered, and limited error\nhandling is possible, so they are mostly unchanged. The error reporting\nis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR\r\n\r\nIn some case, the GDDV returns a package with a buffer which has\nzero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).\r\n\r\nThen the data_vault_read() got NULL point dereference problem when\naccessing the 0x10 value in data_vault.\r\n\r\n[   71.024560] BUG: kernel NULL pointer dereference, address:\n0000000000000010\r\n\r\nThis patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or\nNULL value in data_vault.(CVE-2022-48703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr\r\n\r\nThis node pointer is returned by of_find_compatible_node() with\nrefcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: Fix double free in of_parse_phandle_with_args_map\r\n\r\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of \u0026quot;new\u0026quot; is\nNULL on the first iteration of the inner loop.\r\n\r\nMake sure that this is true in all iterations of the outer\nloop by setting \u0026quot;new\u0026quot; to NULL after its value is assigned to \u0026quot;cur\u0026quot;.\r\n\r\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.(CVE-2023-52679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\r\n\r\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type \u0026apos;int\u0026apos;\r\n\r\nWhen the value of the variable \u0026quot;sd-\u0026gt;params.exposure.gain\u0026quot; exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable \u0026quot;currentexp\u0026quot; cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.(CVE-2023-52764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninit/main.c: Fix potential static_command_line memory overflow\r\n\r\nWe allocate memory of size \u0026apos;xlen + strlen(boot_command_line) + 1\u0026apos; for\nstatic_command_line, but the strings copied into static_command_line are\nextra_command_line and command_line, rather than extra_command_line and\nboot_command_line.\r\n\r\nWhen strlen(command_line) \u0026gt; strlen(boot_command_line), static_command_line\nwill overflow.\r\n\r\nThis patch just recovers strlen(command_line) which was miss-consolidated\nwith strlen(boot_command_line) in the commit f5c7310ac73e (\u0026quot;init/main: add\nchecks for the return value of memblock_alloc*()\u0026quot;)(CVE-2024-26988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: restore set elements when delete set fails\r\n\r\nFrom abort path, nft_mapelem_activate() needs to restore refcounters to\nthe original state. Currently, it uses the set-\u0026gt;ops-\u0026gt;walk() to iterate\nover these set elements. The existing set iterator skips inactive\nelements in the next generation, this does not work from the abort path\nto restore the original state since it has to skip active elements\ninstead (not inactive ones).\r\n\r\nThis patch moves the check for inactive elements to the set iterator\ncallback, then it reverses the logic for the .activate case which\nneeds to skip active elements.\r\n\r\nToggle next generation bit for elements when delete set command is\ninvoked and call nft_clear() from .activate (abort) path to restore the\nnext generation bit.\r\n\r\nThe splat below shows an object in mappings memleak:\r\n\r\n[43929.457523] ------------[ cut here ]------------\n[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[...]\n[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 \u0026lt;0f\u0026gt; 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90\n[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246\n[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000\n[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550\n[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f\n[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0\n[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002\n[43929.458103] FS:  00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[43929.458107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0\n[43929.458114] Call Trace:\n[43929.458118]  \u0026lt;TASK\u0026gt;\n[43929.458121]  ? __warn+0x9f/0x1a0\n[43929.458127]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458188]  ? report_bug+0x1b1/0x1e0\n[43929.458196]  ? handle_bug+0x3c/0x70\n[43929.458200]  ? exc_invalid_op+0x17/0x40\n[43929.458211]  ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]\n[43929.458271]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458332]  nft_mapelem_deactivate+0x24/0x30 [nf_tables]\n[43929.458392]  nft_rhash_walk+0xdd/0x180 [nf_tables]\n[43929.458453]  ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]\n[43929.458512]  ? rb_insert_color+0x2e/0x280\n[43929.458520]  nft_map_deactivate+0xdc/0x1e0 [nf_tables]\n[43929.458582]  ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]\n[43929.458642]  ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]\n[43929.458701]  ? __rcu_read_unlock+0x46/0x70\n[43929.458709]  nft_delset+0xff/0x110 [nf_tables]\n[43929.458769]  nft_flush_table+0x16f/0x460 [nf_tables]\n[43929.458830]  nf_tables_deltable+0x501/0x580 [nf_tables](CVE-2024-27012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid potential panic during recovery\r\n\r\nDuring recovery, if FAULT_BLOCK is on, it is possible that\nf2fs_reserve_new_block() will return -ENOSPC during recovery,\nthen it may trigger panic.\r\n\r\nAlso, if fault injection rate is 1 and only FAULT_BLOCK fault\ntype is on, it may encounter deadloop in loop of block reservation.\r\n\r\nLet\u0026apos;s change as below to fix these issues:\n- remove bug_on() to avoid panic.\n- limit the loop count of block reservation to avoid potential\ndeadloop.(CVE-2024-27032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: Fix clk_core_get NULL dereference\r\n\r\nIt is possible for clk_core_get to dereference a NULL in the following\nsequence:\r\n\r\nclk_core_get()\n    of_clk_get_hw_from_clkspec()\n        __of_clk_get_hw_from_provider()\n            __clk_get_hw()\r\n\r\n__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at\nhw-\u0026gt;core.\r\n\r\nPrior to commit dde4eff47c82 (\u0026quot;clk: Look for parents with clkdev based\nclk_lookups\u0026quot;) the check IS_ERR_OR_NULL() was performed which would have\ncaught the NULL.\r\n\r\nReading the description of this function it talks about returning NULL but\nthat cannot be so at the moment.\r\n\r\nUpdate the function to check for hw before dereferencing it and return NULL\nif hw is NULL.(CVE-2024-27038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: phy: fix phy_get_internal_delay accessing an empty array\r\n\r\nThe phy_get_internal_delay function could try to access to an empty\narray in the case that the driver is calling phy_get_internal_delay\nwithout defining delay_values and rx-internal-delay-ps or\ntx-internal-delay-ps is defined to 0 in the device-tree.\nThis will lead to \u0026quot;unable to handle kernel NULL pointer dereference at\nvirtual address 0\u0026quot;. To avoid this kernel oops, the test should be delay\n\u0026gt;= 0. As there is already delay \u0026lt; 0 test just before, the test could\nonly be size == 0.(CVE-2024-27047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work\r\n\r\nThe workqueue might still be running, when the driver is stopped. To\navoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: do not compare internal table flags on updates\r\n\r\nRestore skipping transaction if table update does not modify flags.(CVE-2024-27065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npower: supply: bq27xxx-i2c: Do not free non existing IRQ\r\n\r\nThe bq27xxx i2c-client may not have an IRQ, in which case\nclient-\u0026gt;irq will be 0. bq27xxx_battery_i2c_probe() already has\nan if (client-\u0026gt;irq) check wrapping the request_threaded_irq().\r\n\r\nBut bq27xxx_battery_i2c_remove() unconditionally calls\nfree_irq(client-\u0026gt;irq) leading to:\r\n\r\n[  190.310742] ------------[ cut here ]------------\n[  190.310843] Trying to free already-free IRQ 0\n[  190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310\r\n\r\nFollowed by a backtrace when unbinding the driver. Add\nan if (client-\u0026gt;irq) to bq27xxx_battery_i2c_remove() mirroring\nprobe() to fix this.(CVE-2024-27412)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST\r\n\r\nIf we received HCI_EV_IO_CAPA_REQUEST while\nHCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote\ndoes support SSP since otherwise this event shouldn\u0026apos;t be generated.(CVE-2024-27416)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mvpp2: clear BM pool before initialization\r\n\r\nRegister value persist after booting the kernel using\nkexec which results in kernel panic. Thus clear the\nBM pool registers before initialisation to fix the issue.(CVE-2024-35837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Skip do PCI error slot reset during RAS recovery\r\n\r\nWhy:\n    The PCI error slot reset maybe triggered after inject ue to UMC multi times, this\n    caused system hang.\n    [  557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume\n    [  557.373718] [drm] PCIE GART of 512M enabled.\n    [  557.373722] [drm] PTB located at 0x0000031FED700000\n    [  557.373788] [drm] VRAM is lost due to GPU reset!\n    [  557.373789] [drm] PSP is resuming...\n    [  557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset\n    [  557.547067] [drm] PCI error: detected callback, state(1)!!\n    [  557.547069] [drm] No support for XGMI hive yet...\n    [  557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter\n    [  557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations\n    [  557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered\n    [  557.610492] [drm] PCI error: slot reset callback!!\n    ...\n    [  560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!\n    [  560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!\n    [  560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI\n    [  560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G           OE     5.15.0-91-generic #101-Ubuntu\n    [  560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023\n    [  560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]\n    [  560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n    [  560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff \u0026lt;48\u0026gt; 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00\n    [  560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202\n    [  560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0\n    [  560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010\n    [  560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08\n    [  560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000\n    [  560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000\n    [  560.803889] FS:  0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000\n    [  560.812973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    [  560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0\n    [  560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    [  560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n    [  560.843444] PKRU: 55555554\n    [  560.846480] Call Trace:\n    [  560.849225]  \u0026lt;TASK\u0026gt;\n    [  560.851580]  ? show_trace_log_lvl+0x1d6/0x2ea\n    [  560.856488]  ? show_trace_log_lvl+0x1d6/0x2ea\n    [  560.861379]  ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n    [  560.867778]  ? show_regs.part.0+0x23/0x29\n    [  560.872293]  ? __die_body.cold+0x8/0xd\n    [  560.876502]  ? die_addr+0x3e/0x60\n    [  560.880238]  ? exc_general_protection+0x1c5/0x410\n    [  560.885532]  ? asm_exc_general_protection+0x27/0x30\n    [  560.891025]  ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n    [  560.898323]  amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n    [  560.904520]  process_one_work+0x228/0x3d0\nHow:\n    In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected\n    all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: fix uninitialized values during inode evict\r\n\r\nIf an iget fails due to not being able to retrieve information\nfrom the server then the inode structure is only partially\ninitialized.  When the inode gets evicted, references to\nuninitialized structures (like fscache cookies) were being\nmade.\r\n\r\nThis patch checks for a bad_inode before doing anything other\nthan clearing the inode from the cache.  Since the inode is\nbad, it shouldn\u0026apos;t have any state associated with it that needs\nto be written back (and there really isn\u0026apos;t a way to complete\nthose anyways).(CVE-2024-36923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: bridge: cdns-mhdp8546: Fix possible null pointer dereference\r\n\r\nIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is\nassigned to mhdp_state-\u0026gt;current_mode, and there is a dereference of it in\ndrm_mode_set_name(), which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate().\r\n\r\nFix this bug add a check of mhdp_state-\u0026gt;current_mode.(CVE-2024-38548)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: add a proper sanity check for endpoints\r\n\r\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\r\n\r\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\r\n\r\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\r\n\r\n[2] Related syzkaller crashes:(CVE-2024-38567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: add error handle to avoid out-of-bounds\r\n\r\nif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should\nbe stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n   MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: davinci: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u0026gt;\ndavinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\r\n\r\nIn lio_vf_rep_copy_packet() pg_info-\u0026gt;page is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\r\n\r\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t  octeon_droq_dispatch_pkt\n\t   octeon_create_recv_info\n\t    ...search in the dispatch_list...\n\t     -\u0026gt;disp_fn(rdisp-\u0026gt;rinfo, ...)\n\t      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u0026gt;page to NULL.\nSo this check looks unneeded and doesn\u0026apos;t solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can\u0026apos;t do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\r\n\r\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/io-wq: Use set_bit() and test_bit() at worker-\u0026gt;flags\r\n\r\nUtilize set_bit() and test_bit() on worker-\u0026gt;flags within io_uring/io-wq\nto address potential data races.\r\n\r\nThe structure io_worker-\u0026gt;flags may be accessed through various data\npaths, leading to concurrency issues. When KCSAN is enabled, it reveals\ndata races occurring in io_worker_handle_work and\nio_wq_activate_free_worker functions.\r\n\r\n\t BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker\n\t write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:\n\t io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)\n\t io_wq_worker (io_uring/io-wq.c:?)\n\u0026lt;snip\u0026gt;\r\n\r\n\t read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:\n\t io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)\n\t io_wq_enqueue (io_uring/io-wq.c:947)\n\t io_queue_iowq (io_uring/io_uring.c:524)\n\t io_req_task_submit (io_uring/io_uring.c:1511)\n\t io_handle_tw_list (io_uring/io_uring.c:1198)\n\u0026lt;snip\u0026gt;\r\n\r\nLine numbers against commit 18daea77cca6 (\u0026quot;Merge tag \u0026apos;for-linus\u0026apos; of\ngit://git.kernel.org/pub/scm/virt/kvm/kvm\u0026quot;).\r\n\r\nThese races involve writes and reads to the same memory location by\ndifferent tasks running on different CPUs. To mitigate this, refactor\nthe code to use atomic operations such as set_bit(), test_bit(), and\nclear_bit() instead of basic \u0026quot;and\u0026quot; and \u0026quot;or\u0026quot; operations. This ensures\nthread-safe manipulation of worker flags.\r\n\r\nAlso, move `create_index` to avoid holes in the structure.(CVE-2024-39508)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\r\n\r\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\r\n\r\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm\u0026apos;s semaphore, and this operation may sleep. This is\nproblematic, because  __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[\u0026lt;ffffffff800060dc\u0026gt;] dump_backtrace+0x1c/0x24\n[\u0026lt;ffffffff8091ef6e\u0026gt;] show_stack+0x2c/0x38\n[\u0026lt;ffffffff8092baf8\u0026gt;] dump_stack_lvl+0x5a/0x72\n[\u0026lt;ffffffff8092bb24\u0026gt;] dump_stack+0x14/0x1c\n[\u0026lt;ffffffff8003b7ac\u0026gt;] __might_resched+0x104/0x10e\n[\u0026lt;ffffffff8003b7f4\u0026gt;] __might_sleep+0x3e/0x62\n[\u0026lt;ffffffff8093276a\u0026gt;] down_write+0x20/0x72\n[\u0026lt;ffffffff8000cf00\u0026gt;] __set_memory+0x82/0x2fa\n[\u0026lt;ffffffff8000d324\u0026gt;] __kernel_map_pages+0x5a/0xd4\n[\u0026lt;ffffffff80196cca\u0026gt;] __alloc_pages_bulk+0x3b2/0x43a\n[\u0026lt;ffffffff8018ee82\u0026gt;] __vmalloc_node_range+0x196/0x6ba\n[\u0026lt;ffffffff80011904\u0026gt;] copy_process+0x72c/0x17ec\n[\u0026lt;ffffffff80012ab4\u0026gt;] kernel_clone+0x60/0x2fe\n[\u0026lt;ffffffff80012f62\u0026gt;] kernel_thread+0x82/0xa0\n[\u0026lt;ffffffff8003552c\u0026gt;] kthreadd+0x14a/0x1be\n[\u0026lt;ffffffff809357de\u0026gt;] ret_from_fork+0xe/0x1c\r\n\r\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.(CVE-2024-40915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Avoid blocking in RCU read-side critical section\r\n\r\nA panic happens in ima_match_policy:\r\n\r\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\nPGD 42f873067 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 5 PID: 1286325 Comm: kubeletmonit.sh\nKdump: loaded Tainted: P\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n               BIOS 0.0.0 02/06/2015\nRIP: 0010:ima_match_policy+0x84/0x450\nCode: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39\n      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d\n      f2 b9 f4 00 0f 84 9c 01 00 00 \u0026lt;44\u0026gt; 85 73 10 74 ea\n      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f\nRSP: 0018:ff71570009e07a80 EFLAGS: 00010207\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200\nRDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000\nRBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739\nR10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970\nR13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001\nFS:  00007f5195b51740(0000)\nGS:ff3e278b12d40000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ima_get_action+0x22/0x30\n process_measurement+0xb0/0x830\n ? page_add_file_rmap+0x15/0x170\n ? alloc_set_pte+0x269/0x4c0\n ? prep_new_page+0x81/0x140\n ? simple_xattr_get+0x75/0xa0\n ? selinux_file_open+0x9d/0xf0\n ima_file_check+0x64/0x90\n path_openat+0x571/0x1720\n do_filp_open+0x9b/0x110\n ? page_counter_try_charge+0x57/0xc0\n ? files_cgroup_alloc_fd+0x38/0x60\n ? __alloc_fd+0xd4/0x250\n ? do_sys_open+0x1bd/0x250\n do_sys_open+0x1bd/0x250\n do_syscall_64+0x5d/0x1d0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nCommit c7423dbdbc9e (\u0026quot;ima: Handle -ESTALE returned by\nima_filter_rule_match()\u0026quot;) introduced call to ima_lsm_copy_rule within a\nRCU read-side critical section which contains kmalloc with GFP_KERNEL.\nThis implies a possible sleep and violates limitations of RCU read-side\ncritical sections on non-PREEMPT systems.\r\n\r\nSleeping within RCU read-side critical section might cause\nsynchronize_rcu() returning early and break RCU protection, allowing a\nUAF to happen.\r\n\r\nThe root cause of this issue could be described as follows:\n|\tThread A\t|\tThread B\t|\n|\t\t\t|ima_match_policy\t|\n|\t\t\t|  rcu_read_lock\t|\n|ima_lsm_update_rule\t|\t\t\t|\n|  synchronize_rcu\t|\t\t\t|\n|\t\t\t|    kmalloc(GFP_KERNEL)|\n|\t\t\t|      sleep\t\t|\n==\u0026gt; synchronize_rcu returns early\n|  kfree(entry)\t\t|\t\t\t|\n|\t\t\t|    entry = entry-\u0026gt;next|\n==\u0026gt; UAF happens and entry now becomes NULL (or could be anything).\n|\t\t\t|    entry-\u0026gt;action\t|\n==\u0026gt; Accessing entry might cause panic.\r\n\r\nTo fix this issue, we are converting all kmalloc that is called within\nRCU read-side critical section to use GFP_ATOMIC.\r\n\r\n[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list\r\n\r\nUse list_for_each_entry_safe() to allow iterating through the list and\ndeleting the entry in the iteration process. The descriptor is freed via\nidxd_desc_complete() and there\u0026apos;s a slight chance may cause issue for\nthe list iterator when the descriptor is reused by another thread\nwithout it being deleted from the list.(CVE-2024-40956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL dereference in rt6_probe()\r\n\r\nsyzbot caught a NULL dereference in rt6_probe() [1]\r\n\r\nBail out if  __in6_dev_get() returns NULL.\r\n\r\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n  find_rr_leaf net/ipv6/route.c:853 [inline]\n  rt6_select net/ipv6/route.c:897 [inline]\n  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n  pol_lookup_func include/net/ip6_fib.h:616 [inline]\n  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x6b6/0x1140 fs/read_write.c:590\n  ksys_write+0x1f8/0x260 fs/read_write.c:643\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmips: bmips: BCM6358: make sure CBR is correctly set\r\n\r\nIt was discovered that some device have CBR address set to 0 causing\nkernel panic when arch_sync_dma_for_cpu_all is called.\r\n\r\nThis was notice in situation where the system is booted from TP1 and\nBMIPS_GET_CBR() returns 0 instead of a valid address and\n!!(read_c0_brcm_cmt_local() \u0026amp; (1 \u0026lt;\u0026lt; 31)); not failing.\r\n\r\nThe current check whether RAC flush should be disabled or not are not\nenough hence lets check if CBR is a valid address or not.(CVE-2024-40963)\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\next4: do not create EA inode under buffer lock\r\n\r\next4_xattr_set_entry() creates new EA inodes while holding buffer lock\non the external xattr block. This is problematic as it nests all the\nallocation locking (which acquires locks on other buffers) under the\nbuffer lock. This can even deadlock when the filesystem is corrupted and\ne.g. quota file is setup to contain xattr block as data block. Move the\nallocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrop_monitor: replace spin_lock by raw_spin_lock\r\n\r\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026amp;data-\u0026gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last  enabled at (139908): [\u0026lt;ffffffffb1df2b33\u0026gt;] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u0026lt;ffffffffb19bd03d\u0026gt;] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last  enabled at (139892): [\u0026lt;ffffffffb07a1083\u0026gt;] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u0026lt;ffffffffb0909b33\u0026gt;] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u0026lt;ffffffffb1de786b\u0026gt;] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\r\n\r\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\r\n\r\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.(CVE-2024-40980)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last  enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n  spin_unlock_bh include/linux/spinlock.h:396 [inline]\n  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n  process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n  process_scheduled_works kernel/workqueue.c:2706 [inline]\n  worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n  kthread+0x288/0x310 kernel/kthread.c:388\n  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nssb: Fix potential NULL pointer dereference in ssb_device_uevent()\r\n\r\nThe ssb_device_uevent() function first attempts to convert the \u0026apos;dev\u0026apos; pointer\nto \u0026apos;struct ssb_device *\u0026apos;. However, it mistakenly dereferences \u0026apos;dev\u0026apos; before\nperforming the NULL check, potentially leading to a NULL pointer\ndereference if \u0026apos;dev\u0026apos; is NULL.\r\n\r\nTo fix this issue, move the NULL check before dereferencing the \u0026apos;dev\u0026apos; pointer,\nensuring that the pointer is valid before attempting to use it.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\r\n\r\nsyzbot found hanging tasks waiting on rtnl_lock [1]\r\n\r\nA reproducer is available in the syzbot bug.\r\n\r\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\r\n\r\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\r\n\r\n[1]\r\n\r\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u0026lt;TASK\u0026gt;\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: don\u0026apos;t allow mapping the MMIO HDP page with large pages\r\n\r\nWe don\u0026apos;t get the right offset in that case.  The GPU has\nan unused 4K area of the register BAR space into which you can\nremap registers.  We remap the HDP flush registers into this\nspace to allow userspace (CPU or GPU) to flush the HDP when it\nupdates VRAM.  However, on systems with \u0026gt;4K pages, we end up\nexposing PAGE_SIZE of MMIO space.(CVE-2024-41011)",
  "id": "OESA-2024-1942",
  "modified": "2026-08-06T11:07:24Z",
  "published": "2024-08-02T11:07:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52764"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27065"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27412"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27416"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35837"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36923"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38548"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39471"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40945"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40963"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40967"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41011"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47205",
    "CVE-2022-48703",
    "CVE-2022-48859",
    "CVE-2023-52679",
    "CVE-2023-52764",
    "CVE-2024-26988",
    "CVE-2024-27012",
    "CVE-2024-27032",
    "CVE-2024-27038",
    "CVE-2024-27047",
    "CVE-2024-27052",
    "CVE-2024-27065",
    "CVE-2024-27412",
    "CVE-2024-27416",
    "CVE-2024-34777",
    "CVE-2024-35837",
    "CVE-2024-35931",
    "CVE-2024-36923",
    "CVE-2024-37078",
    "CVE-2024-38548",
    "CVE-2024-38567",
    "CVE-2024-38607",
    "CVE-2024-38611",
    "CVE-2024-39471",
    "CVE-2024-39475",
    "CVE-2024-39476",
    "CVE-2024-39484",
    "CVE-2024-39506",
    "CVE-2024-39508",
    "CVE-2024-40915",
    "CVE-2024-40945",
    "CVE-2024-40947",
    "CVE-2024-40956",
    "CVE-2024-40960",
    "CVE-2024-40963",
    "CVE-2024-40967",
    "CVE-2024-40972",
    "CVE-2024-40980",
    "CVE-2024-40981",
    "CVE-2024-40982",
    "CVE-2024-40995",
    "CVE-2024-41011"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "bpftool-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "bpftool-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2408.1.0.0288.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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: musb: tusb6010: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47181)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix memory ordering between normal and ordered work functions\r\n\r\nOrdered work functions aren\u0026apos;t guaranteed to be handled by the same thread\nwhich executed the normal work functions. The only way execution between\nnormal/ordered functions is synchronized is via the WORK_DONE_BIT,\nunfortunately the used bitops don\u0026apos;t guarantee any ordering whatsoever.\r\n\r\nThis manifested as seemingly inexplicable crashes on ARM64, where\nasync_chunk::inode is seen as non-null in async_cow_submit which causes\nsubmit_compressed_extents to be called and crash occurs because\nasync_chunk::inode suddenly became NULL. The call trace was similar to:\r\n\r\n    pc : submit_compressed_extents+0x38/0x3d0\n    lr : async_cow_submit+0x50/0xd0\n    sp : ffff800015d4bc20\r\n\r\n    \u0026lt;registers omitted for brevity\u0026gt;\r\n\r\n    Call trace:\n     submit_compressed_extents+0x38/0x3d0\n     async_cow_submit+0x50/0xd0\n     run_ordered_work+0xc8/0x280\n     btrfs_work_helper+0x98/0x250\n     process_one_work+0x1f0/0x4ac\n     worker_thread+0x188/0x504\n     kthread+0x110/0x114\n     ret_from_fork+0x10/0x18\r\n\r\nFix this by adding respective barrier calls which ensure that all\naccesses preceding setting of WORK_DONE_BIT are strictly ordered before\nsetting the flag. At the same time add a read barrier after reading of\nWORK_DONE_BIT in run_ordered_work which ensures all subsequent loads\nwould be strictly ordered after reading the bit. This in turn ensures\nare all accesses before WORK_DONE_BIT are going to be strictly ordered\nbefore any access that can occur in ordered_func.(CVE-2021-47189)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa2-eth: fix use-after-free in dpaa2_eth_remove\r\n\r\nAccess to netdev after free_netdev() will cause use-after-free bug.\nMove debug log before free_netdev() call to avoid it.(CVE-2021-47204)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: host: ohci-tmio: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47206)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvsock: remove vsock from connected table when connect is interrupted by a signal\r\n\r\nvsock_connect() expects that the socket could already be in the\nTCP_ESTABLISHED state when the connecting task wakes up with a signal\npending. If this happens the socket will be in the connected table, and\nit is not removed when the socket state is reset. In this situation it\u0026apos;s\ncommon for the process to retry connect(), and if the connection is\nsuccessful the socket will be added to the connected table a second\ntime, corrupting the list.\r\n\r\nPrevent this by calling vsock_remove_connected() if a signal is received\nwhile waiting for a connection. This is harmless if the socket is not in\nthe connected table, and if it is in the table then removing it will\nprevent list corruption from a double add.\r\n\r\nNote for backporting: this patch requires d5afa82c977e (\u0026quot;vsock: correct\nremoval of socket from the list\u0026quot;), which is in all current stable trees\nexcept 4.9.y.(CVE-2022-48786)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: at86rf230: Stop leaking skb\u0026apos;s\r\n\r\nUpon error the ieee802154_xmit_complete() helper is not called. Only\nieee802154_wake_queue() is called manually. In the Tx case we then leak\nthe skb structure.\r\n\r\nFree the skb structure upon error before returning when appropriate.\r\n\r\nAs the \u0026apos;is_tx = 0\u0026apos; cannot be moved in the complete handler because of a\npossible race between the delay in switching to STATE_RX_AACK_ON and a\nnew interrupt, we introduce an intermediate \u0026apos;was_tx\u0026apos; boolean just for\nthis purpose.\r\n\r\nThere is no Fixes tag applying here, many changes have been made on this\narea and the issue kind of always existed.(CVE-2022-48794)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt_ioctl: fix array_index_nospec in vt_setactivate\r\n\r\narray_index_nospec ensures that an out-of-bounds value is set to zero\non the transient path. Decreasing the value by one afterwards causes\na transient integer underflow. vsa.console should be decreased first\nand then sanitized with array_index_nospec.\r\n\r\nKasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh\nRazavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU\nAmsterdam.(CVE-2022-48804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: f_fs: Fix use-after-free for epfile\r\n\r\nConsider a case where ffs_func_eps_disable is called from\nffs_func_disable as part of composition switch and at the\nsame time ffs_epfile_release get called from userspace.\nffs_epfile_release will free up the read buffer and call\nffs_data_closed which in turn destroys ffs-\u0026gt;epfiles and\nmark it as NULL. While this was happening the driver has\nalready initialized the local epfile in ffs_func_eps_disable\nwhich is now freed and waiting to acquire the spinlock. Once\nspinlock is acquired the driver proceeds with the stale value\nof epfile and tries to free the already freed read buffer\ncausing use-after-free.\r\n\r\nFollowing is the illustration of the race:\r\n\r\n      CPU1                                  CPU2\r\n\r\n   ffs_func_eps_disable\n   epfiles (local copy)\n\t\t\t\t\tffs_epfile_release\n\t\t\t\t\tffs_data_closed\n\t\t\t\t\tif (last file closed)\n\t\t\t\t\tffs_data_reset\n\t\t\t\t\tffs_data_clear\n\t\t\t\t\tffs_epfiles_destroy\nspin_lock\ndereference epfiles\r\n\r\nFix this races by taking epfiles local copy \u0026amp; assigning it under\nspinlock and if epfiles(local) is null then update it in ffs-\u0026gt;epfiles\nthen finally destroy it.\nExtending the scope further from the race, protecting the ep related\nstructures, and concurrent accesses.(CVE-2022-48822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: aiptek - properly check endpoint type\r\n\r\nSyzbot reported warning in usb_submit_urb() which is caused by wrong\nendpoint type. There was a check for the number of endpoints, but not\nfor the type of endpoint.\r\n\r\nFix it by replacing old desc.bNumEndpoints check with\nusb_find_common_endpoints() helper for finding endpoints\r\n\r\nFail log:\r\n\r\nusb 5-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nWorkqueue: usb_hub_wq hub_event\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830\n input_open_device+0x1bb/0x320 drivers/input/input.c:629\n kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593(CVE-2022-48836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nMIPS: smp: fill in sibling and core maps earlier\r\n\r\nAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),\n2-core 2-thread-per-core interAptiv (CPS-driven) started emitting\nthe following:\r\n\r\n[    0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))\n[    0.048183] ------------[ cut here ]------------\n[    0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240\n[    0.048220] Modules linked in:\n[    0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f\n[    0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1\n[    0.048278]         830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000\n[    0.048307]         00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000\n[    0.048334]         00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34\n[    0.048361]         817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933\n[    0.048389]         ...\n[    0.048396] Call Trace:\n[    0.048399] [\u0026lt;8105a7bc\u0026gt;] show_stack+0x3c/0x140\n[    0.048424] [\u0026lt;8131c2a0\u0026gt;] dump_stack_lvl+0x60/0x80\n[    0.048440] [\u0026lt;8108b5c0\u0026gt;] __warn+0xc0/0xf4\n[    0.048454] [\u0026lt;8108b658\u0026gt;] warn_slowpath_fmt+0x64/0x10c\n[    0.048467] [\u0026lt;810bd418\u0026gt;] sched_core_cpu_starting+0x198/0x240\n[    0.048483] [\u0026lt;810c6514\u0026gt;] sched_cpu_starting+0x14/0x80\n[    0.048497] [\u0026lt;8108c0f8\u0026gt;] cpuhp_invoke_callback_range+0x78/0x140\n[    0.048510] [\u0026lt;8108d914\u0026gt;] notify_cpu_starting+0x94/0x140\n[    0.048523] [\u0026lt;8106593c\u0026gt;] start_secondary+0xbc/0x280\n[    0.048539]\n[    0.048543] ---[ end trace 0000000000000000 ]---\n[    0.048636] Synchronize counters for CPU 1: done.\r\n\r\n...for each but CPU 0/boot.\nBasic debug printks right before the mentioned line say:\r\n\r\n[    0.048170] CPU: 1, smt_mask:\r\n\r\nSo smt_mask, which is sibling mask obviously, is empty when entering\nthe function.\nThis is critical, as sched_core_cpu_starting() calculates\ncore-scheduling parameters only once per CPU start, and it\u0026apos;s crucial\nto have all the parameters filled in at that moment (at least it\nuses cpu_smt_mask() which in fact is `\u0026amp;cpu_sibling_map[cpu]` on\nMIPS).\r\n\r\nA bit of debugging led me to that set_cpu_sibling_map() performing\nthe actual map calculation, was being invocated after\nnotify_cpu_start(), and exactly the latter function starts CPU HP\ncallback round (sched_core_cpu_starting() is basically a CPU HP\ncallback).\nWhile the flow is same on ARM64 (maps after the notifier, although\nbefore calling set_cpu_online()), x86 started calculating sibling\nmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see\n[0] for the reference). Neither me nor my brief tests couldn\u0026apos;t find\nany potential caveats in calculating the maps right after performing\ndelay calibration, but the WARN splat is now gone.\nThe very same debug prints now yield exactly what I expected from\nthem:\r\n\r\n[    0.048433] CPU: 1, smt_mask: 0-1\r\n\r\n[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef(CVE-2022-48845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: gdm724x: fix use after free in gdm_lte_rx()\r\n\r\nThe netif_rx_ni() function frees the skb so we can\u0026apos;t dereference it to\nsave the skb-\u0026gt;len.(CVE-2022-48851)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFC: port100: fix use-after-free in port100_send_complete\r\n\r\nSyzbot reported UAF in port100_send_complete(). The root case is in\nmissing usb_kill_urb() calls on error handling path of -\u0026gt;probe function.\r\n\r\nport100_send_complete() accesses devm allocated memory which will be\nfreed on probe failure. We should kill this urbs before returning an\nerror from probe function to prevent reported use-after-free\r\n\r\nFail log:\r\n\r\nBUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935\nRead of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold+0x83/0xdf mm/kasan/report.c:459\n port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935\n __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670\r\n\r\n...\r\n\r\nAllocated by task 1255:\n kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\n kasan_set_track mm/kasan/common.c:45 [inline]\n set_alloc_info mm/kasan/common.c:436 [inline]\n ____kasan_kmalloc mm/kasan/common.c:515 [inline]\n ____kasan_kmalloc mm/kasan/common.c:474 [inline]\n __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524\n alloc_dr drivers/base/devres.c:116 [inline]\n devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823\n devm_kzalloc include/linux/device.h:209 [inline]\n port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502\r\n\r\nFreed by task 1255:\n kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\n kasan_set_track+0x21/0x30 mm/kasan/common.c:45\n kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370\n ____kasan_slab_free mm/kasan/common.c:366 [inline]\n ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328\n kasan_slab_free include/linux/kasan.h:236 [inline]\n __cache_free mm/slab.c:3437 [inline]\n kfree+0xf8/0x2b0 mm/slab.c:3794\n release_nodes+0x112/0x1a0 drivers/base/devres.c:501\n devres_release_all+0x114/0x190 drivers/base/devres.c:530\n really_probe+0x626/0xcc0 drivers/base/dd.c:670(CVE-2022-48857)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: Fix double free in of_parse_phandle_with_args_map\r\n\r\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of \u0026quot;new\u0026quot; is\nNULL on the first iteration of the inner loop.\r\n\r\nMake sure that this is true in all iterations of the outer\nloop by setting \u0026quot;new\u0026quot; to NULL after its value is assigned to \u0026quot;cur\u0026quot;.\r\n\r\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.(CVE-2023-52679)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s drm/exynos device driver in\u00a0exynos_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\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: add a proper sanity check for endpoints\r\n\r\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\r\n\r\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\r\n\r\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\r\n\r\n[2] Related syzkaller crashes:(CVE-2024-38567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\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\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: davinci: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u0026gt;\ndavinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\r\n\r\nIn lio_vf_rep_copy_packet() pg_info-\u0026gt;page is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\r\n\r\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t  octeon_droq_dispatch_pkt\n\t   octeon_create_recv_info\n\t    ...search in the dispatch_list...\n\t     -\u0026gt;disp_fn(rdisp-\u0026gt;rinfo, ...)\n\t      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u0026gt;page to NULL.\nSo this check looks unneeded and doesn\u0026apos;t solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can\u0026apos;t do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\r\n\r\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)\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\nima: Avoid blocking in RCU read-side critical section\r\n\r\nA panic happens in ima_match_policy:\r\n\r\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\nPGD 42f873067 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 5 PID: 1286325 Comm: kubeletmonit.sh\nKdump: loaded Tainted: P\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n               BIOS 0.0.0 02/06/2015\nRIP: 0010:ima_match_policy+0x84/0x450\nCode: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39\n      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d\n      f2 b9 f4 00 0f 84 9c 01 00 00 \u0026lt;44\u0026gt; 85 73 10 74 ea\n      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f\nRSP: 0018:ff71570009e07a80 EFLAGS: 00010207\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200\nRDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000\nRBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739\nR10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970\nR13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001\nFS:  00007f5195b51740(0000)\nGS:ff3e278b12d40000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ima_get_action+0x22/0x30\n process_measurement+0xb0/0x830\n ? page_add_file_rmap+0x15/0x170\n ? alloc_set_pte+0x269/0x4c0\n ? prep_new_page+0x81/0x140\n ? simple_xattr_get+0x75/0xa0\n ? selinux_file_open+0x9d/0xf0\n ima_file_check+0x64/0x90\n path_openat+0x571/0x1720\n do_filp_open+0x9b/0x110\n ? page_counter_try_charge+0x57/0xc0\n ? files_cgroup_alloc_fd+0x38/0x60\n ? __alloc_fd+0xd4/0x250\n ? do_sys_open+0x1bd/0x250\n do_sys_open+0x1bd/0x250\n do_syscall_64+0x5d/0x1d0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nCommit c7423dbdbc9e (\u0026quot;ima: Handle -ESTALE returned by\nima_filter_rule_match()\u0026quot;) introduced call to ima_lsm_copy_rule within a\nRCU read-side critical section which contains kmalloc with GFP_KERNEL.\nThis implies a possible sleep and violates limitations of RCU read-side\ncritical sections on non-PREEMPT systems.\r\n\r\nSleeping within RCU read-side critical section might cause\nsynchronize_rcu() returning early and break RCU protection, allowing a\nUAF to happen.\r\n\r\nThe root cause of this issue could be described as follows:\n|\tThread A\t|\tThread B\t|\n|\t\t\t|ima_match_policy\t|\n|\t\t\t|  rcu_read_lock\t|\n|ima_lsm_update_rule\t|\t\t\t|\n|  synchronize_rcu\t|\t\t\t|\n|\t\t\t|    kmalloc(GFP_KERNEL)|\n|\t\t\t|      sleep\t\t|\n==\u0026gt; synchronize_rcu returns early\n|  kfree(entry)\t\t|\t\t\t|\n|\t\t\t|    entry = entry-\u0026gt;next|\n==\u0026gt; UAF happens and entry now becomes NULL (or could be anything).\n|\t\t\t|    entry-\u0026gt;action\t|\n==\u0026gt; Accessing entry might cause panic.\r\n\r\nTo fix this issue, we are converting all kmalloc that is called within\nRCU read-side critical section to use GFP_ATOMIC.\r\n\r\n[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL dereference in rt6_probe()\r\n\r\nsyzbot caught a NULL dereference in rt6_probe() [1]\r\n\r\nBail out if  __in6_dev_get() returns NULL.\r\n\r\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n  find_rr_leaf net/ipv6/route.c:853 [inline]\n  rt6_select net/ipv6/route.c:897 [inline]\n  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n  pol_lookup_func include/net/ip6_fib.h:616 [inline]\n  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x6b6/0x1140 fs/read_write.c:590\n  ksys_write+0x1f8/0x260 fs/read_write.c:643\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last  enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n  spin_unlock_bh include/linux/spinlock.h:396 [inline]\n  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n  process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n  process_scheduled_works kernel/workqueue.c:2706 [inline]\n  worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n  kthread+0x288/0x310 kernel/kthread.c:388\n  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\r\n\r\nsyzbot found hanging tasks waiting on rtnl_lock [1]\r\n\r\nA reproducer is available in the syzbot bug.\r\n\r\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\r\n\r\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\r\n\r\n[1]\r\n\r\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u0026lt;TASK\u0026gt;\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)",
  "id": "OESA-2024-1944",
  "modified": "2026-08-06T11:07:24Z",
  "published": "2024-08-02T11:07:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47181"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47204"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47206"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48786"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48822"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48836"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48845"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48851"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22386"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38627"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47181",
    "CVE-2021-47189",
    "CVE-2021-47204",
    "CVE-2021-47206",
    "CVE-2022-48786",
    "CVE-2022-48794",
    "CVE-2022-48804",
    "CVE-2022-48822",
    "CVE-2022-48828",
    "CVE-2022-48836",
    "CVE-2022-48845",
    "CVE-2022-48851",
    "CVE-2022-48857",
    "CVE-2023-52679",
    "CVE-2024-22386",
    "CVE-2024-37078",
    "CVE-2024-38567",
    "CVE-2024-38611",
    "CVE-2024-38627",
    "CVE-2024-39475",
    "CVE-2024-39484",
    "CVE-2024-39506",
    "CVE-2024-40942",
    "CVE-2024-40947",
    "CVE-2024-40960",
    "CVE-2024-40978",
    "CVE-2024-40981",
    "CVE-2024-40988",
    "CVE-2024-40995"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "perf-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-37.0.0.44.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-37.0.0.44.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-37.0.0.44.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "perf-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-37.0.0.44.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-37.0.0.44.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-37.0.0.44.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\nefi: libstub: only free priv.runtime_map when allocated\r\n\r\npriv.runtime_map is only allocated when efi_novamap is not set.\nOtherwise, it is an uninitialized value.  In the error path, it is freed\nunconditionally.  Avoid passing an uninitialized value to free_pool.\nFree priv.runtime_map only when it was allocated.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-33619)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfpga: region: add owner module and take its refcount\r\n\r\nThe current implementation of the fpga region assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the region\nduring programming if the parent device does not have a driver.\r\n\r\nTo address this problem, add a module owner pointer to the fpga_region\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering a region to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the region as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a region without setting the owner.\r\n\r\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga region.(CVE-2024-35247)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neeprom: at24: fix memory corruption race condition\r\n\r\nIf the eeprom is not accessible, an nvmem device will be registered, the\nread will fail, and the device will be torn down. If another driver\naccesses the nvmem device after the teardown, it will reference\ninvalid memory.\r\n\r\nMove the failure point before registering the nvmem device.(CVE-2024-35848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix module reference leakage from bdev_open_by_dev error path\r\n\r\nAt the time bdev_may_open() is called, module reference is grabbed\nalready, hence module reference should be released if bdev_may_open()\nfailed.\r\n\r\nThis problem is found by code review.(CVE-2024-35859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/slab: make __free(kfree) accept error pointers\r\n\r\nCurrently, if an automatically freed allocation is an error pointer that\nwill lead to a crash.  An example of this is in wm831x_gpio_dbg_show().\r\n\r\n   171\tchar *label __free(kfree) = gpiochip_dup_line_label(chip, i);\n   172\tif (IS_ERR(label)) {\n   173\t\tdev_err(wm831x-\u0026gt;dev, \u0026quot;Failed to duplicate label\\n\u0026quot;);\n   174\t\tcontinue;\n   175  }\r\n\r\nThe auto clean up function should check for error pointers as well,\notherwise we\u0026apos;re going to keep hitting issues like this.(CVE-2024-36890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix access violation during port device removal\r\n\r\nTesting with KASAN and syzkaller revealed a bug in port.c:disable_store():\nusb_hub_to_struct_hub() can return NULL if the hub that the port belongs to\nis concurrently removed, but the function does not check for this\npossibility before dereferencing the returned value.\r\n\r\nIt turns out that the first dereference is unnecessary, since hub-\u0026gt;intfdev\nis the parent of the port device, so it can be changed easily.  Adding a\ncheck for hub == NULL prevents further problems.\r\n\r\nThe same bug exists in the disable_show() routine, and it can be fixed the\nsame way.(CVE-2024-36896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: Fix use after free in lineinfo_changed_notify\r\n\r\nThe use-after-free issue occurs as follows: when the GPIO chip device file\nis being closed by invoking gpio_chrdev_release(), watched_lines is freed\nby bitmap_free(), but the unregistration of lineinfo_changed_nb notifier\nchain failed due to waiting write rwsem. Additionally, one of the GPIO\nchip\u0026apos;s lines is also in the release process and holds the notifier chain\u0026apos;s\nread rwsem. Consequently, a race condition leads to the use-after-free of\nwatched_lines.\r\n\r\nHere is the typical stack when issue happened:\r\n\r\n[free]\ngpio_chrdev_release()\n  --\u0026gt; bitmap_free(cdev-\u0026gt;watched_lines)                  \u0026lt;-- freed\n  --\u0026gt; blocking_notifier_chain_unregister()\n    --\u0026gt; down_write(\u0026amp;nh-\u0026gt;rwsem)                          \u0026lt;-- waiting rwsem\n          --\u0026gt; __down_write_common()\n            --\u0026gt; rwsem_down_write_slowpath()\n                  --\u0026gt; schedule_preempt_disabled()\n                    --\u0026gt; schedule()\r\n\r\n[use]\nst54spi_gpio_dev_release()\n  --\u0026gt; gpio_free()\n    --\u0026gt; gpiod_free()\n      --\u0026gt; gpiod_free_commit()\n        --\u0026gt; gpiod_line_state_notify()\n          --\u0026gt; blocking_notifier_call_chain()\n            --\u0026gt; down_read(\u0026amp;nh-\u0026gt;rwsem);                  \u0026lt;-- held rwsem\n            --\u0026gt; notifier_call_chain()\n              --\u0026gt; lineinfo_changed_notify()\n                --\u0026gt; test_bit(xxxx, cdev-\u0026gt;watched_lines) \u0026lt;-- use after free\r\n\r\nThe side effect of the use-after-free issue is that a GPIO line event is\nbeing generated for userspace where it shouldn\u0026apos;t. However, since the chrdev\nis being closed, userspace won\u0026apos;t have the chance to read that event anyway.\r\n\r\nTo fix the issue, call the bitmap_free() function after the unregistration\nof lineinfo_changed_nb notifier chain.(CVE-2024-36899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral 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: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n  sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n  sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n  sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n  sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n  sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n  sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n  sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n  __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n  sctp_connect net/sctp/socket.c:4819 [inline]\n  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n  __sys_connect_file net/socket.c:2048 [inline]\n  __sys_connect+0x2df/0x310 net/socket.c:2065\n  __do_sys_connect net/socket.c:2075 [inline]\n  __se_sys_connect net/socket.c:2072 [inline]\n  __x64_sys_connect+0x7a/0x90 net/socket.c:2072\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(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nReapply \u0026quot;drm/qxl: simplify qxl_fence_wait\u0026quot;\r\n\r\nThis reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.\r\n\r\nStephen Rostedt reports:\n \u0026quot;I went to run my tests on my VMs and the tests hung on boot up.\n  Unfortunately, the most I ever got out was:\r\n\r\n  [   93.607888] Testing event system initcall: OK\n  [   93.667730] Running tests on all trace events:\n  [   93.669757] Testing all events: OK\n  [   95.631064] ------------[ cut here ]------------\n  Timed out after 60 seconds\u0026quot;\r\n\r\nand further debugging points to a possible circular locking dependency\nbetween the console_owner locking and the worker pool locking.\r\n\r\nReverting the commit allows Steve\u0026apos;s VM to boot to completion again.\r\n\r\n[ This may obviously result in the \u0026quot;[TTM] Buffer eviction failed\u0026quot;\n  messages again, which was the reason for that original revert. But at\n  this point this seems preferable to a non-booting system... ](CVE-2024-36944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: only translate RWX permissions for plain 9P2000\r\n\r\nGarbage in plain 9P2000\u0026apos;s perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.(CVE-2024-36964)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Add a timeout to acquire the command queue semaphore\r\n\r\nPrevent forced completion handling on an entry that has not yet been\nassigned an index, causing an out of bounds access on idx = -22.\nInstead of waiting indefinitely for the sem, blocking flow now waits for\nindex to be allocated or a sem acquisition timeout before beginning the\ntimer for FW completion.\r\n\r\nKernel log example:\nmlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion(CVE-2024-38556)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrcu: Fix buffer overflow in print_cpu_stall_info()\r\n\r\nThe rcuc-starvation output from print_cpu_stall_info() might overflow the\nbuffer if there is a huge difference in jiffies difference.  The situation\nmight seem improbable, but computers sometimes get very confused about\ntime, which can result in full-sized integers, and, in this case,\nbuffer overflow.\r\n\r\nAlso, the unsigned jiffies difference is printed using %ld, which is\nnormally for signed integers.  This is intentional for debugging purposes,\nbut it is not obvious from the code.\r\n\r\nThis commit therefore changes sprintf() to snprintf() and adds a\nclarifying comment about intention of %ld format.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38576)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: Fix deadlocks with kctl removals at disconnection\r\n\r\nIn snd_card_disconnect(), we set card-\u0026gt;shutdown flag at the beginning,\ncall callbacks and do sync for card-\u0026gt;power_ref_sleep waiters at the\nend.  The callback may delete a kctl element, and this can lead to a\ndeadlock when the device was in the suspended state.  Namely:\r\n\r\n* A process waits for the power up at snd_power_ref_and_wait() in\n  snd_ctl_info() or read/write() inside card-\u0026gt;controls_rwsem.\r\n\r\n* The system gets disconnected meanwhile, and the driver tries to\n  delete a kctl via snd_ctl_remove*(); it tries to take\n  card-\u0026gt;controls_rwsem again, but this is already locked by the\n  above.  Since the sleeper isn\u0026apos;t woken up, this deadlocks.\r\n\r\nAn easy fix is to wake up sleepers before processing the driver\ndisconnect callbacks but right after setting the card-\u0026gt;shutdown flag.\nThen all sleepers will abort immediately, and the code flows again.\r\n\r\nSo, basically this patch moves the wait_event() call at the right\ntiming.  While we\u0026apos;re at it, just to be sure, call wait_event_all()\ninstead of wait_event(), although we don\u0026apos;t use exclusive events on\nthis queue for now.(CVE-2024-38600)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - validate slices count returned by FW\r\n\r\nThe function adf_send_admin_tl_start() enables the telemetry (TL)\nfeature on a QAT device by sending the ICP_QAT_FW_TL_START message to\nthe firmware. This triggers the FW to start writing TL data to a DMA\nbuffer in memory and returns an array containing the number of\naccelerators of each type (slices) supported by this HW.\nThe pointer to this array is stored in the adf_tl_hw_data data\nstructure called slice_cnt.\r\n\r\nThe array slice_cnt is then used in the function tl_print_dev_data()\nto report in debugfs only statistics about the supported accelerators.\nAn incorrect value of the elements in slice_cnt might lead to an out\nof bounds memory read.\nAt the moment, there isn\u0026apos;t an implementation of FW that returns a wrong\nvalue, but for robustness validate the slice count array returned by FW.(CVE-2024-38606)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkunit/fortify: Fix mismatched kvalloc()/vfree() usage\r\n\r\nThe kv*() family of tests were accidentally freeing with vfree() instead\nof kvfree(). Use kvfree() instead.(CVE-2024-38617)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: add error handle to avoid out-of-bounds\r\n\r\nif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should\nbe stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension\r\n\r\nIf a process module does not have base config extension then the same\nformat applies to all of it\u0026apos;s inputs and the process-\u0026gt;base_config_ext is\nNULL, causing NULL dereference when specifically crafted topology and\nsequences used.(CVE-2024-39473)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mc: Fix graph walk in media_pipeline_start\r\n\r\nThe graph walk tries to follow all links, even if they are not between\npads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.\r\n\r\nFix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK\nlinks.(CVE-2024-39481)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/drm_file: Fix pid refcounting race\r\n\r\n\u0026lt;maarten.lankhorst@linux.intel.com\u0026gt;, Maxime Ripard\n\u0026lt;mripard@kernel.org\u0026gt;, Thomas Zimmermann \u0026lt;tzimmermann@suse.de\u0026gt;\r\n\r\nfilp-\u0026gt;pid is supposed to be a refcounted pointer; however, before this\npatch, drm_file_update_pid() only increments the refcount of a struct\npid after storing a pointer to it in filp-\u0026gt;pid and dropping the\ndev-\u0026gt;filelist_mutex, making the following race possible:\r\n\r\nprocess A               process B\n=========               =========\n                        begin drm_file_update_pid\n                        mutex_lock(\u0026amp;dev-\u0026gt;filelist_mutex)\n                        rcu_replace_pointer(filp-\u0026gt;pid, \u0026lt;pid B\u0026gt;, 1)\n                        mutex_unlock(\u0026amp;dev-\u0026gt;filelist_mutex)\nbegin drm_file_update_pid\nmutex_lock(\u0026amp;dev-\u0026gt;filelist_mutex)\nrcu_replace_pointer(filp-\u0026gt;pid, \u0026lt;pid A\u0026gt;, 1)\nmutex_unlock(\u0026amp;dev-\u0026gt;filelist_mutex)\nget_pid(\u0026lt;pid A\u0026gt;)\nsynchronize_rcu()\nput_pid(\u0026lt;pid B\u0026gt;)   *** pid B reaches refcount 0 and is freed here ***\n                        get_pid(\u0026lt;pid B\u0026gt;)   *** UAF ***\n                        synchronize_rcu()\n                        put_pid(\u0026lt;pid A\u0026gt;)\r\n\r\nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y\nbecause it requires RCU to detect a quiescent state in code that is not\nexplicitly calling into the scheduler.\r\n\r\nThis race leads to use-after-free of a \u0026quot;struct pid\u0026quot;.\nIt is probably somewhat hard to hit because process A has to pass\nthrough a synchronize_rcu() operation while process B is between\nmutex_unlock() and get_pid().\r\n\r\nFix it by ensuring that by the time a pointer to the current task\u0026apos;s pid\nis stored in the file, an extra reference to the pid has been taken.\r\n\r\nThis fix also removes the condition for synchronize_rcu(); I think\nthat optimization is unnecessary complexity, since in that case we\nwould usually have bailed out on the lockless check above.(CVE-2024-39486)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - Fix ADF_DEV_RESET_SYNC memory leak\r\n\r\nUsing completion_done to determine whether the caller has gone\naway only works after a complete call.  Furthermore it\u0026apos;s still\npossible that the caller has not yet called wait_for_completion,\nresulting in another potential UAF.\r\n\r\nFix this by making the caller use cancel_work_sync and then freeing\nthe memory safely.(CVE-2024-39493)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: zoned: fix use-after-free due to race with dev replace\r\n\r\nWhile loading a zone\u0026apos;s info during creation of a block group, we can race\nwith a device replace operation and then trigger a use-after-free on the\ndevice that was just replaced (source device of the replace operation).\r\n\r\nThis happens because at btrfs_load_zone_info() we extract a device from\nthe chunk map into a local variable and then use the device while not\nunder the protection of the device replace rwsem. So if there\u0026apos;s a device\nreplace operation happening when we extract the device and that device\nis the source of the replace operation, we will trigger a use-after-free\nif before we finish using the device the replace operation finishes and\nfrees the device.\r\n\r\nFix this by enlarging the critical section under the protection of the\ndevice replace rwsem so that all uses of the device are done inside the\ncritical section.(CVE-2024-39496)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ipset: Fix race between namespace cleanup and gc in the list:set type\r\n\r\nLion Ackermann reported that there is a race condition between namespace cleanup\nin ipset and the garbage collection of the list:set type. The namespace\ncleanup can destroy the list:set type of sets while the gc of the set type is\nwaiting to run in rcu cleanup. The latter uses data from the destroyed set which\nthus leads use after free. The patch contains the following parts:\r\n\r\n- When destroying all sets, first remove the garbage collectors, then wait\n  if needed and then destroy the sets.\n- Fix the badly ordered \u0026quot;wait then remove gc\u0026quot; for the destroy a single set\n  case.\n- Fix the missing rcu locking in the list:set type in the userspace test\n  case.\n- Use proper RCU list handlings in the list:set type.\r\n\r\nThe patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).(CVE-2024-39503)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cachefiles: remove requests from xarray during flushing requests  Even with CACHEFILES_DEAD set, we can still read the requests, so in the following concurrency the request may be used after it has been freed:       mount  |   daemon_thread1    |    daemon_thread2 ------------------------------------------------------------  cachefiles_ondemand_init_object   cachefiles_ondemand_send_req    REQ_A = kzalloc(sizeof(*req) + data_len)    wait_for_completion(\u0026amp;REQ_A-\u0026gt;done)             cachefiles_daemon_read              cachefiles_ondemand_daemon_read                                   // close dev fd                                   cachefiles_flush_reqs                                    complete(\u0026amp;REQ_A-\u0026gt;done)    kfree(REQ_A)               xa_lock(\u0026amp;cache-\u0026gt;reqs);               cachefiles_ondemand_select_req                 req-\u0026gt;msg.opcode != CACHEFILES_OP_READ                 // req use-after-free !!!               xa_unlock(\u0026amp;cache-\u0026gt;reqs);                                    xa_destroy(\u0026amp;cache-\u0026gt;reqs)  Hence remove requests from cache-\u0026gt;reqs when flushing them to avoid accessing freed requests.(CVE-2024-40900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Always stop health timer during driver removal\r\n\r\nCurrently, if teardown_hca fails to execute during driver removal, mlx5\ndoes not stop the health timer. Afterwards, mlx5 continue with driver\nteardown. This may lead to a UAF bug, which results in page fault\nOops[1], since the health timer invokes after resources were freed.\r\n\r\nHence, stop the health monitor even if teardown_hca fails.\r\n\r\n[1]\nmlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: cleanup\nmlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource\nmlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup\nBUG: unable to handle page fault for address: ffffa26487064230\nPGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Tainted: G           OE     -------  ---  6.7.0-68.fc38.x86_64 #1\nHardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020\nRIP: 0010:ioread32be+0x34/0x60\nRSP: 0018:ffffa26480003e58 EFLAGS: 00010292\nRAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0\nRDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230\nRBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8\nR10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0\nR13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0\nFS:  0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x175/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n ? ioread32be+0x34/0x60\n mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core]\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n poll_health+0x42/0x230 [mlx5_core]\n ? __next_timer_interrupt+0xbc/0x110\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n call_timer_fn+0x21/0x130\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n __run_timers+0x222/0x2c0\n run_timer_softirq+0x1d/0x40\n __do_softirq+0xc9/0x2c8\n __irq_exit_rcu+0xa6/0xc0\n sysvec_apic_timer_interrupt+0x72/0x90\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:cpuidle_enter_state+0xcc/0x440\n ? cpuidle_enter_state+0xbd/0x440\n cpuidle_enter+0x2d/0x40\n do_idle+0x20d/0x270\n cpu_startup_entry+0x2a/0x30\n rest_init+0xd0/0xd0\n arch_call_rest_init+0xe/0x30\n start_kernel+0x709/0xa90\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0x96/0xa0\n secondary_startup_64_no_verify+0x18f/0x19b\n---[ end trace 0000000000000000 ]---(CVE-2024-40906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Set run context for rawtp test_run callback\r\n\r\nsyzbot reported crash when rawtp program executed through the\ntest_run interface calls bpf_get_attach_cookie helper or any\nother helper that touches task-\u0026gt;bpf_ctx pointer.\r\n\r\nSetting the run context (task-\u0026gt;bpf_ctx pointer) for test_run\ncallback.(CVE-2024-40908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: defer exposing anon_fd until after copy_to_user() succeeds\r\n\r\nAfter installing the anonymous fd, we can now see it in userland and close\nit. However, at this point we may not have gotten the reference count of\nthe cache, but we will put it during colse fd, so this may cause a cache\nUAF.\r\n\r\nSo grab the cache reference count before fd_install(). In addition, by\nkernel convention, fd is taken over by the user land after fd_install(),\nand the kernel should not call close_fd() after that, i.e., it should call\nfd_install() after everything is ready, thus fd_install() is called after\ncopy_to_user() succeeds.(CVE-2024-40913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mst: fix suspicious rcu usage in br_mst_set_state\r\n\r\nI converted br_mst_set_state to RCU to avoid a vlan use-after-free\nbut forgot to change the vlan group dereference helper. Switch to vlan\ngroup RCU deref helper to fix the suspicious rcu usage warning.(CVE-2024-40920)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mst: pass vlan group directly to br_mst_vlan_set_state\r\n\r\nPass the already obtained vlan group pointer to br_mst_vlan_set_state()\ninstead of dereferencing it again. Each caller has already correctly\ndereferenced it for their context. This change is required for the\nfollowing suspicious RCU dereference fix. No functional changes\nintended.(CVE-2024-40921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/rsrc: don\u0026apos;t lock while !TASK_RUNNING\r\n\r\nThere is a report of io_rsrc_ref_quiesce() locking a mutex while not\nTASK_RUNNING, which is due to forgetting restoring the state back after\nio_run_task_work_sig() and attempts to break out of the waiting loop.\r\n\r\ndo not call blocking ops when !TASK_RUNNING; state=1 set at\n[\u0026lt;ffffffff815d2494\u0026gt;] prepare_to_wait+0xa4/0x380\nkernel/sched/wait.c:237\nWARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099\n__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nRIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752\n io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253\n io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799\n __io_uring_register io_uring/register.c:424 [inline]\n __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6f/0x77(CVE-2024-40922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: flush all requests after setting CACHEFILES_DEAD\r\n\r\nIn ondemand mode, when the daemon is processing an open request, if the\nkernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write()\nwill always return -EIO, so the daemon can\u0026apos;t pass the copen to the kernel.\nThen the kernel process that is waiting for the copen triggers a hung_task.\r\n\r\nSince the DEAD state is irreversible, it can only be exited by closing\n/dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark\nthe cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to\navoid the above hungtask. We may still be able to read some of the cached\ndata before closing the fd of /dev/cachefiles.\r\n\r\nNote that this relies on the patch that adds reference counting to the req,\notherwise it may UAF.(CVE-2024-40935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()\r\n\r\nUse {READ,WRITE}_ONCE() to access kvm-\u0026gt;last_boosted_vcpu to ensure the\nloads and stores are atomic.  In the extremely unlikely scenario the\ncompiler tears the stores, it\u0026apos;s theoretically possible for KVM to attempt\nto get a vCPU using an out-of-bounds index, e.g. if the write is split\ninto multiple 8-bit stores, and is paired with a 32-bit load on a VM with\n257 vCPUs:\r\n\r\n  CPU0                              CPU1\n  last_boosted_vcpu = 0xff;\r\n\r\n                                    (last_boosted_vcpu = 0x100)\n                                    last_boosted_vcpu[15:8] = 0x01;\n  i = (last_boosted_vcpu = 0x1ff)\n                                    last_boosted_vcpu[7:0] = 0x00;\r\n\r\n  vcpu = kvm-\u0026gt;vcpu_array[0x1ff];\r\n\r\nAs detected by KCSAN:\r\n\r\n  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]\r\n\r\n  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:\n  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm\n  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel\n  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?\n\t\t arch/x86/kvm/vmx/vmx.c:6606) kvm_intel\n  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm\n  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm\n  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm\n  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)\n  __x64_sys_ioctl (fs/ioctl.c:890)\n  x64_sys_call (arch/x86/entry/syscall_64.c:33)\n  do_syscall_64 (arch/x86/entry/common.c:?)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n  read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:\n  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm\n  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel\n  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?\n\t\t\tarch/x86/kvm/vmx/vmx.c:6606) kvm_intel\n  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm\n  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm\n  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm\n  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)\n  __x64_sys_ioctl (fs/ioctl.c:890)\n  x64_sys_call (arch/x86/entry/syscall_64.c:33)\n  do_syscall_64 (arch/x86/entry/common.c:?)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n  value changed: 0x00000012 -\u0026gt; 0x00000000(CVE-2024-40953)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: zoned: allocate dummy checksums for zoned NODATASUM writes\r\n\r\nShin\u0026apos;ichiro reported that when he\u0026apos;s running fstests\u0026apos; test-case\nbtrfs/167 on emulated zoned devices, he\u0026apos;s seeing the following NULL\npointer dereference in \u0026apos;btrfs_zone_finish_endio()\u0026apos;:\r\n\r\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n  CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G        W          6.10.0-rc2-kts+ #4\n  Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n  Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]\n  RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\r\n\r\n  RSP: 0018:ffff88867f107a90 EFLAGS: 00010206\n  RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534\n  RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088\n  RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028\n  R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000\n  R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210\n  FS:  0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __die_body.cold+0x19/0x27\n   ? die_addr+0x46/0x70\n   ? exc_general_protection+0x14f/0x250\n   ? asm_exc_general_protection+0x26/0x30\n   ? do_raw_read_unlock+0x44/0x70\n   ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n   btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs]\n   ? __pfx_lock_release+0x10/0x10\n   ? do_raw_write_lock+0x90/0x260\n   ? __pfx_do_raw_write_lock+0x10/0x10\n   ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]\n   ? _raw_write_unlock+0x23/0x40\n   ? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]\n   ? lock_acquire+0x435/0x500\n   btrfs_work_helper+0x1b1/0xa70 [btrfs]\n   ? __schedule+0x10a8/0x60b0\n   ? __pfx___might_resched+0x10/0x10\n   process_one_work+0x862/0x1410\n   ? __pfx_lock_acquire+0x10/0x10\n   ? __pfx_process_one_work+0x10/0x10\n   ? assign_work+0x16c/0x240\n   worker_thread+0x5e6/0x1010\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x2c3/0x3a0\n   ? trace_irq_enable.constprop.0+0xce/0x110\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x31/0x70\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u0026lt;/TASK\u0026gt;\r\n\r\nEnabling CONFIG_BTRFS_ASSERT revealed the following assertion to\ntrigger:\r\n\r\n  assertion failed: !list_empty(\u0026amp;ordered-\u0026gt;list), in fs/btrfs/zoned.c:1815\r\n\r\nThis indicates, that we\u0026apos;re missing the checksums list on the\nordered_extent. As btrfs/167 is doing a NOCOW write this is to be\nexpected.\r\n\r\nFurther analysis with drgn confirmed the assumption:\r\n\r\n  \u0026gt;\u0026gt;\u0026gt; inode = prog.crashed_thread().stack_trace()[11][\u0026apos;ordered\u0026apos;].inode\n  \u0026gt;\u0026gt;\u0026gt; btrfs_inode = drgn.container_of(inode, \u0026quot;struct btrfs_inode\u0026quot;, \\\n         \t\t\t\t\u0026quot;vfs_inode\u0026quot;)\n  \u0026gt;\u0026gt;\u0026gt; print(btrfs_inode.flags)\n  (u32)1\r\n\r\nAs zoned emulation mode simulates conventional zones on regular devices,\nwe cannot use zone-append for writing. But we\u0026apos;re only attaching dummy\nchecksums if we\u0026apos;re doing a zone-append write.\r\n\r\nSo for NOCOW zoned data writes on conventional zones, also attach a\ndummy checksum.(CVE-2024-40962)\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\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last  enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n  spin_unlock_bh include/linux/spinlock.h:396 [inline]\n  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n  process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n  process_scheduled_works kernel/workqueue.c:2706 [inline]\n  worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n  kthread+0x288/0x310 kernel/kthread.c:388\n  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix a memory leak in nr_heartbeat_expiry()\r\n\r\nsyzbot reported a memory leak in nr_create() [0].\r\n\r\nCommit 409db27e3a2e (\u0026quot;netrom: Fix use-after-free of a listening socket.\u0026quot;)\nadded sock_hold() to the nr_heartbeat_expiry() function, where\na) a socket has a SOCK_DESTROY flag or\nb) a listening socket has a SOCK_DEAD flag.\r\n\r\nBut in the case \u0026quot;a,\u0026quot; when the SOCK_DESTROY flag is set, the file descriptor\nhas already been closed and the nr_release() function has been called.\nSo it makes no sense to hold the reference count because no one will\ncall another nr_destroy_socket() and put it as in the case \u0026quot;b.\u0026quot;\r\n\r\nnr_connect\n  nr_establish_data_link\n    nr_start_heartbeat\r\n\r\nnr_release\n  switch (nr-\u0026gt;state)\n  case NR_STATE_3\n    nr-\u0026gt;state = NR_STATE_2\n    sock_set_flag(sk, SOCK_DESTROY);\r\n\r\n                        nr_rx_frame\n                          nr_process_rx_frame\n                            switch (nr-\u0026gt;state)\n                            case NR_STATE_2\n                              nr_state2_machine()\n                                nr_disconnect()\n                                  nr_sk(sk)-\u0026gt;state = NR_STATE_0\n                                  sock_set_flag(sk, SOCK_DEAD)\r\n\r\n                        nr_heartbeat_expiry\n                          switch (nr-\u0026gt;state)\n                          case NR_STATE_0\n                            if (sock_flag(sk, SOCK_DESTROY) ||\n                               (sk-\u0026gt;sk_state == TCP_LISTEN\n                                 \u0026amp;\u0026amp; sock_flag(sk, SOCK_DEAD)))\n                               sock_hold()  // ( !!! )\n                               nr_destroy_socket()\r\n\r\nTo fix the memory leak, let\u0026apos;s call sock_hold() only for a listening socket.\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.\r\n\r\n[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16(CVE-2024-41006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix too early release of tcx_entry\r\n\r\nPedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported\nan issue that the tcx_entry can be released too early leading to a use\nafter free (UAF) when an active old-style ingress or clsact qdisc with a\nshared tc block is later replaced by another ingress or clsact instance.\r\n\r\nEssentially, the sequence to trigger the UAF (one example) can be as follows:\r\n\r\n  1. A network namespace is created\n  2. An ingress qdisc is created. This allocates a tcx_entry, and\n     \u0026amp;tcx_entry-\u0026gt;miniq is stored in the qdisc\u0026apos;s miniqp-\u0026gt;p_miniq. At the\n     same time, a tcf block with index 1 is created.\n  3. chain0 is attached to the tcf block. chain0 must be connected to\n     the block linked to the ingress qdisc to later reach the function\n     tcf_chain0_head_change_cb_del() which triggers the UAF.\n  4. Create and graft a clsact qdisc. This causes the ingress qdisc\n     created in step 1 to be removed, thus freeing the previously linked\n     tcx_entry:\r\n\r\n     rtnetlink_rcv_msg()\n       =\u0026gt; tc_modify_qdisc()\n         =\u0026gt; qdisc_create()\n           =\u0026gt; clsact_init() [a]\n         =\u0026gt; qdisc_graft()\n           =\u0026gt; qdisc_destroy()\n             =\u0026gt; __qdisc_destroy()\n               =\u0026gt; ingress_destroy() [b]\n                 =\u0026gt; tcx_entry_free()\n                   =\u0026gt; kfree_rcu() // tcx_entry freed\r\n\r\n  5. Finally, the network namespace is closed. This registers the\n     cleanup_net worker, and during the process of releasing the\n     remaining clsact qdisc, it accesses the tcx_entry that was\n     already freed in step 4, causing the UAF to occur:\r\n\r\n     cleanup_net()\n       =\u0026gt; ops_exit_list()\n         =\u0026gt; default_device_exit_batch()\n           =\u0026gt; unregister_netdevice_many()\n             =\u0026gt; unregister_netdevice_many_notify()\n               =\u0026gt; dev_shutdown()\n                 =\u0026gt; qdisc_put()\n                   =\u0026gt; clsact_destroy() [c]\n                     =\u0026gt; tcf_block_put_ext()\n                       =\u0026gt; tcf_chain0_head_change_cb_del()\n                         =\u0026gt; tcf_chain_head_change_item()\n                           =\u0026gt; clsact_chain_head_change()\n                             =\u0026gt; mini_qdisc_pair_swap() // UAF\r\n\r\nThere are also other variants, the gist is to add an ingress (or clsact)\nqdisc with a specific shared block, then to replace that qdisc, waiting\nfor the tcx_entry kfree_rcu() to be executed and subsequently accessing\nthe current active qdisc\u0026apos;s miniq one way or another.\r\n\r\nThe correct fix is to turn the miniq_active boolean into a counter. What\ncan be observed, at step 2 above, the counter transitions from 0-\u0026gt;1, at\nstep [a] from 1-\u0026gt;2 (in order for the miniq object to remain active during\nthe replacement), then in [b] from 2-\u0026gt;1 and finally [c] 1-\u0026gt;0 with the\neventual release. The reference counter in general ranges from [0,2] and\nit does not need to be atomic since all access to the counter is protected\nby the rtnl mutex. With this in place, there is no longer a UAF happening\nand the tcx_entry is freed at the correct time.(CVE-2024-41010)\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\nfs/ntfs3: Add a check for attr_names and oatbl\r\n\r\nAdded out-of-bound checking for *ane (ATTR_NAME_ENTRY).(CVE-2024-41018)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Validate ff offset\r\n\r\nThis adds sanity checks for ff offset. There is a check\non rt-\u0026gt;first_free at first, but walking through by ff\nwithout any check. If the second ff is a large offset.\nWe may encounter an out-of-bound read.(CVE-2024-41019)\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\ns390/mm: Fix VM_FAULT_HWPOISON handling in do_exception()\r\n\r\nThere is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on\ns390. Therefore we do not expect to see VM_FAULT_HWPOISON in\ndo_exception().\r\n\r\nHowever, since commit af19487f00f3 (\u0026quot;mm: make PTE_MARKER_SWAPIN_ERROR more\ngeneral\u0026quot;), it is possible to see VM_FAULT_HWPOISON in combination with\nPTE_MARKER_POISONED, even on architectures that do not support HWPOISON\notherwise. In this case, we will end up on the BUG() in do_exception().\r\n\r\nFix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar\nto x86 when MEMORY_FAILURE is not configured. Also print unexpected fault\nflags, for easier debugging.\r\n\r\nNote that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot\nsupport swap entries on other levels than PTE level.(CVE-2024-41021)\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\nfirmware: cs_dsp: Fix overflow checking of wmfw header\r\n\r\nFix the checking that firmware file buffer is large enough for the\nwmfw header, to prevent overrunning the buffer.\r\n\r\nThe original code tested that the firmware data buffer contained\nenough bytes for the sums of the size of the structs\r\n\r\n\twmfw_header + wmfw_adsp1_sizes + wmfw_footer\r\n\r\nBut wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and\nHalo Core the equivalent struct is wmfw_adsp2_sizes, which is\n4 bytes longer. So the length check didn\u0026apos;t guarantee that there\nare enough bytes in the firmware buffer for a header with\nwmfw_adsp2_sizes.\r\n\r\nThis patch splits the length check into three separate parts. Each\nof the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked\nseparately before they are used.(CVE-2024-41039)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix UAF when resolving a clash\r\n\r\nKASAN reports the following UAF:\r\n\r\n BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n Read of size 1 at addr ffff888c07603600 by task handler130/6469\r\n\r\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  dump_stack_lvl+0x48/0x70\n  print_address_description.constprop.0+0x33/0x3d0\n  print_report+0xc0/0x2b0\n  kasan_report+0xd0/0x120\n  __asan_load1+0x6c/0x80\n  tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n  tcf_ct_act+0x886/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\n  __irq_exit_rcu+0x82/0xc0\n  irq_exit_rcu+0xe/0x20\n  common_interrupt+0xa1/0xb0\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  asm_common_interrupt+0x27/0x40\r\n\r\n Allocated by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_alloc_info+0x1e/0x40\n  __kasan_krealloc+0x133/0x190\n  krealloc+0xaa/0x130\n  nf_ct_ext_add+0xed/0x230 [nf_conntrack]\n  tcf_ct_act+0x1095/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\n Freed by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_free_info+0x2b/0x60\n  ____kasan_slab_free+0x180/0x1f0\n  __kasan_slab_free+0x12/0x30\n  slab_free_freelist_hook+0xd2/0x1a0\n  __kmem_cache_free+0x1a2/0x2f0\n  kfree+0x78/0x120\n  nf_conntrack_free+0x74/0x130 [nf_conntrack]\n  nf_ct_destroy+0xb2/0x140 [nf_conntrack]\n  __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]\n  nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]\n  __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]\n  tcf_ct_act+0x12ad/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\nThe ct may be dropped if a clash has been resolved but is still passed to\nthe tcf_ct_flow_table_process_conn function for further usage. This issue\ncan be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().\r\n\r\nsyzkaller triggered the warning [0] in udp_v4_early_demux().\r\n\r\nIn udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount\nof the looked-up sk and use sock_pfree() as skb-\u0026gt;destructor, so we check\nSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace\nperiod.\r\n\r\nCurrently, SOCK_RCU_FREE is flagged for a bound socket after being put\ninto the hash table.  Moreover, the SOCK_RCU_FREE check is done too early\nin udp_v[46]_early_demux() and sk_lookup(), so there could be a small race\nwindow:\r\n\r\n  CPU1                                 CPU2\n  ----                                 ----\n  udp_v4_early_demux()                 udp_lib_get_port()\n  |                                    |- hlist_add_head_rcu()\n  |- sk = __udp4_lib_demux_lookup()    |\n  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));\n                                       `- sock_set_flag(sk, SOCK_RCU_FREE)\r\n\r\nWe had the same bug in TCP and fixed it in commit 871019b22d1b (\u0026quot;net:\nset SOCK_RCU_FREE before inserting socket into hashtable\u0026quot;).\r\n\r\nLet\u0026apos;s apply the same fix for UDP.\r\n\r\n[0]:\nWARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nModules linked in:\nCPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nCode: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe \u0026lt;0f\u0026gt; 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52\nRSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c\nRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001\nRBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680\nR13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e\nFS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349\n ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624\n __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738\n netif_receive_skb_internal net/core/dev.c:5824 [inline]\n netif_receive_skb+0x271/0x300 net/core/dev.c:5884\n tun_rx_batched drivers/net/tun.c:1549 [inline]\n tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002\n tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x76f/0x8d0 fs/read_write.c:590\n ksys_write+0xbf/0x190 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x41/0x50 fs/read_write.c:652\n x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fc44a68bc1f\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48\nRSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f\nR\n---truncated---(CVE-2024-41041)\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\nbpf: Defer work in bpf_timer_cancel_and_free\r\n\r\nCurrently, the same case as previous patch (two timer callbacks trying\nto cancel each other) can be invoked through bpf_map_update_elem as\nwell, or more precisely, freeing map elements containing timers. Since\nthis relies on hrtimer_cancel as well, it is prone to the same deadlock\nsituation as the previous patch.\r\n\r\nIt would be sufficient to use hrtimer_try_to_cancel to fix this problem,\nas the timer cannot be enqueued after async_cancel_and_free. Once\nasync_cancel_and_free has been done, the timer must be reinitialized\nbefore it can be armed again. The callback running in parallel trying to\narm the timer will fail, and freeing bpf_hrtimer without waiting is\nsufficient (given kfree_rcu), and bpf_timer_cb will return\nHRTIMER_NORESTART, preventing the timer from being rearmed again.\r\n\r\nHowever, there exists a UAF scenario where the callback arms the timer\nbefore entering this function, such that if cancellation fails (due to\ntimer callback invoking this routine, or the target timer callback\nrunning concurrently). In such a case, if the timer expiration is\nsignificantly far in the future, the RCU grace period expiration\nhappening before it will free the bpf_hrtimer state and along with it\nthe struct hrtimer, that is enqueued.\r\n\r\nHence, it is clear cancellation needs to occur after\nasync_cancel_and_free, and yet it cannot be done inline due to deadlock\nissues. We thus modify bpf_timer_cancel_and_free to defer work to the\nglobal workqueue, adding a work_struct alongside rcu_head (both used at\n_different_ points of time, so can share space).\r\n\r\nUpdate existing code comments to reflect the new state of affairs.(CVE-2024-41045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nskmsg: Skip zero length skb in sk_msg_recvmsg\r\n\r\nWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch\nplatform, the following kernel panic occurs:\r\n\r\n  [...]\n  Oops[#1]:\n  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18\n  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018\n     ... ...\n     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560\n    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0\n   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n   PRMD: 0000000c (PPLV0 +PIE +PWE)\n   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n   BADV: 0000000000000040\n   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)\n  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack\n  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)\n  Stack : ...\n  Call Trace:\n  [\u0026lt;9000000004162774\u0026gt;] copy_page_to_iter+0x74/0x1c0\n  [\u0026lt;90000000048bf6c0\u0026gt;] sk_msg_recvmsg+0x120/0x560\n  [\u0026lt;90000000049f2b90\u0026gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0\n  [\u0026lt;90000000049aae34\u0026gt;] inet_recvmsg+0x54/0x100\n  [\u0026lt;900000000481ad5c\u0026gt;] sock_recvmsg+0x7c/0xe0\n  [\u0026lt;900000000481e1a8\u0026gt;] __sys_recvfrom+0x108/0x1c0\n  [\u0026lt;900000000481e27c\u0026gt;] sys_recvfrom+0x1c/0x40\n  [\u0026lt;9000000004c076ec\u0026gt;] do_syscall+0x8c/0xc0\n  [\u0026lt;9000000003731da4\u0026gt;] handle_syscall+0xc4/0x160\n  Code: ...\n  ---[ end trace 0000000000000000 ]---\n  Kernel panic - not syncing: Fatal exception\n  Kernel relocated by 0x3510000\n   .text @ 0x9000000003710000\n   .data @ 0x9000000004d70000\n   .bss  @ 0x9000000006469400\n  ---[ end Kernel panic - not syncing: Fatal exception ]---\n  [...]\r\n\r\nThis crash happens every time when running sockmap_skb_verdict_shutdown\nsubtest in sockmap_basic.\r\n\r\nThis crash is because a NULL pointer is passed to page_address() in the\nsk_msg_recvmsg(). Due to the different implementations depending on the\narchitecture, page_address(NULL) will trigger a panic on Loongarch\nplatform but not on x86 platform. So this bug was hidden on x86 platform\nfor a while, but now it is exposed on Loongarch platform. The root cause\nis that a zero length skb (skb-\u0026gt;len == 0) was put on the queue.\r\n\r\nThis zero length skb is a TCP FIN packet, which was sent by shutdown(),\ninvoked in test_sockmap_skb_verdict_shutdown():\r\n\r\n\tshutdown(p1, SHUT_WR);\r\n\r\nIn this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no\npage is put to this sge (see sg_set_page in sg_set_page), but this empty\nsge is queued into ingress_msg list.\r\n\r\nAnd in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by\nsg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it\nto kmap_local_page() and to page_address(), then kernel panics.\r\n\r\nTo solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),\nif copy is zero, that means it\u0026apos;s a zero length skb, skip invoking\ncopy_page_to_iter(). We are using the EFAULT return triggered by\ncopy_page_to_iter to check for is_fin in tcp_bpf.c.(CVE-2024-41048)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: fix potential use-after-free in posix_lock_inode\r\n\r\nLight Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().\nThe request pointer had been changed earlier to point to a lock entry\nthat was added to the inode\u0026apos;s list. However, before the tracepoint could\nfire, another task raced in and freed that lock.\r\n\r\nFix this by moving the tracepoint inside the spinlock, which should\nensure that this doesn\u0026apos;t happen.(CVE-2024-41049)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files\r\n\r\nUse strnlen() instead of strlen() on the algorithm and coefficient name\nstring arrays in V1 wmfw files.\r\n\r\nIn V1 wmfw files the name is a NUL-terminated string in a fixed-size\narray. cs_dsp should protect against overrunning the array if the NUL\nterminator is missing.(CVE-2024-41056)\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\nBluetooth: hci_core: cancel all works upon hci_unregister_dev()\r\n\r\nsyzbot is reporting that calling hci_release_dev() from hci_error_reset()\ndue to hci_dev_put() from hci_error_reset() can cause deadlock at\ndestroy_workqueue(), for hci_error_reset() is called from\nhdev-\u0026gt;req_workqueue which destroy_workqueue() needs to flush.\r\n\r\nWe need to make sure that hdev-\u0026gt;{rx_work,cmd_work,tx_work} which are\nqueued into hdev-\u0026gt;workqueue and hdev-\u0026gt;{power_on,error_reset} which are\nqueued into hdev-\u0026gt;req_workqueue are no longer running by the moment\r\n\r\n       destroy_workqueue(hdev-\u0026gt;workqueue);\n       destroy_workqueue(hdev-\u0026gt;req_workqueue);\r\n\r\nare called from hci_release_dev().\r\n\r\nCall cancel_work_sync() on these work items from hci_unregister_dev()\nas soon as hdev-\u0026gt;list is removed from hci_dev_list.(CVE-2024-41063)\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\nASoC: topology: Fix references to freed memory\r\n\r\nMost users after parsing a topology file, release memory used by it, so\nhaving pointer references directly into topology file contents is wrong.\nUse devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)\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\ncachefiles: Set object to close if ondemand_id \u0026lt; 0 in copen\r\n\r\nIf copen is maliciously called in the user mode, it may delete the request\ncorresponding to the random id. And the request may have not been read yet.\r\n\r\nNote that when the object is set to reopen, the open request will be done\nwith the still reopen state in above case. As a result, the request\ncorresponding to this object is always skipped in select_req function, so\nthe read request is never completed and blocks other process.\r\n\r\nFix this issue by simply set object to close if its id \u0026lt; 0 in copen.(CVE-2024-41074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: add consistency check for copen/cread\r\n\r\nThis prevents malicious processes from completing random copen/cread\nrequests and crashing the system. Added checks are listed below:\r\n\r\n  * Generic, copen can only complete open requests, and cread can only\n    complete read requests.\n  * For copen, ondemand_id must not be 0, because this indicates that the\n    request has not been read by the daemon.\n  * For cread, the object corresponding to fd and req should be the same.(CVE-2024-41075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSv4: Fix memory leak in nfs4_set_security_label\r\n\r\nWe leak nfs_fattr and nfs4_label every time we set a security xattr.(CVE-2024-41076)\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\nio_uring: fix possible deadlock in io_register_iowq_max_workers()\r\n\r\nThe io_register_iowq_max_workers() function calls io_put_sq_data(),\nwhich acquires the sqd-\u0026gt;lock without releasing the uring_lock.\nSimilar to the commit 009ad9f0c6ee (\u0026quot;io_uring: drop ctx-\u0026gt;uring_lock\nbefore acquiring sqd-\u0026gt;lock\u0026quot;), this can lead to a potential deadlock\nsituation.\r\n\r\nTo resolve this issue, the uring_lock is released before calling\nio_put_sq_data(), and then it is re-acquired after the function call.\r\n\r\nThis change ensures that the locks are acquired in the correct\norder, preventing the possibility of a deadlock.(CVE-2024-41080)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncxl/mem: Fix no cxl_nvd during pmem region auto-assembling\r\n\r\nWhen CXL subsystem is auto-assembling a pmem region during cxl\nendpoint port probing, always hit below calltrace.\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000078\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x24/0x70\n  ? page_fault_oops+0x82/0x160\n  ? do_user_addr_fault+0x65/0x6b0\n  ? exc_page_fault+0x7d/0x170\n  ? asm_exc_page_fault+0x26/0x30\n  ? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]\n  ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem]\n  cxl_bus_probe+0x1b/0x60 [cxl_core]\n  really_probe+0x173/0x410\n  ? __pfx___device_attach_driver+0x10/0x10\n  __driver_probe_device+0x80/0x170\n  driver_probe_device+0x1e/0x90\n  __device_attach_driver+0x90/0x120\n  bus_for_each_drv+0x84/0xe0\n  __device_attach+0xbc/0x1f0\n  bus_probe_device+0x90/0xa0\n  device_add+0x51c/0x710\n  devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core]\n  cxl_bus_probe+0x1b/0x60 [cxl_core]\r\n\r\nThe cxl_nvd of the memdev needs to be available during the pmem region\nprobe. Currently the cxl_nvd is registered after the endpoint port probe.\nThe endpoint probe, in the case of autoassembly of regions, can cause a\npmem region probe requiring the not yet available cxl_nvd. Adjust the\nsequence so this dependency is met.\r\n\r\nThis requires adding a port parameter to cxl_find_nvdimm_bridge() that\ncan be used to query the ancestor root port. The endpoint port is not\nyet available, but will share a common ancestor with its parent, so\nstart the query from there instead.(CVE-2024-41085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntap: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tap_get_user_xdp() path, which could cause a corrupted skb to be\nsent downstack. Even before the skb is transmitted, the\ntap_get_user_xdp()--\u0026gt;skb_set_network_header() may assume the size is more\nthan ETH_HLEN. Once transmitted, this could either cause out-of-bound\naccess beyond the actual length, or confuse the underlayer with incorrect\nor inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tap_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tap_get_user() does.\r\n\r\nCVE: CVE-2024-41090(CVE-2024-41090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tun_xdp_one() path, which could cause a corrupted skb to be sent\ndownstack. Even before the skb is transmitted, the\ntun_xdp_one--\u0026gt;eth_type_trans() may access the Ethernet header although it\ncan be less than ETH_HLEN. Once transmitted, this could either cause\nout-of-bound access beyond the actual length, or confuse the underlayer\nwith incorrect or inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tun_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted for\nIFF_TAP.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tun_get_user() does.\r\n\r\nCVE: CVE-2024-41091(CVE-2024-41091)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/MSI: Fix UAF in msi_capability_init\r\n\r\nKFENCE reports the following UAF:\r\n\r\n BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488\r\n\r\n Use-after-free read at 0x0000000024629571 (in kfence-#12):\n  __pci_enable_msi_range+0x2c0/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\r\n\r\n kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128\r\n\r\n allocated by task 81 on cpu 7 at 10.808142s:\n  __kmem_cache_alloc_node+0x1f0/0x2bc\n  kmalloc_trace+0x44/0x138\n  msi_alloc_desc+0x3c/0x9c\n  msi_domain_insert_msi_desc+0x30/0x78\n  msi_setup_msi_desc+0x13c/0x184\n  __pci_enable_msi_range+0x258/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\r\n\r\n freed by task 81 on cpu 7 at 10.811436s:\n  msi_domain_free_descs+0xd4/0x10c\n  msi_domain_free_locked.part.0+0xc0/0x1d8\n  msi_domain_alloc_irqs_all_locked+0xb4/0xbc\n  pci_msi_setup_msi_irqs+0x30/0x4c\n  __pci_enable_msi_range+0x2a8/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\r\n\r\nDescriptor allocation done in:\n__pci_enable_msi_range\n    msi_capability_init\n        msi_setup_msi_desc\n            msi_insert_msi_desc\n                msi_domain_insert_msi_desc\n                    msi_alloc_desc\n                        ...\r\n\r\nFreed in case of failure in __msi_domain_alloc_locked()\n__pci_enable_msi_range\n    msi_capability_init\n        pci_msi_setup_msi_irqs\n            msi_domain_alloc_irqs_all_locked\n                msi_domain_alloc_locked\n                    __msi_domain_alloc_locked =\u0026gt; fails\n                    msi_domain_free_locked\n                        ...\r\n\r\nThat failure propagates back to pci_msi_setup_msi_irqs() in\nmsi_capability_init() which accesses the descriptor for unmasking in the\nerror exit path.\r\n\r\nCure it by copying the descriptor and using the copy for the error exit path\nunmask operation.\r\n\r\n[ tglx: Massaged change log ](CVE-2024-41096)\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\niio: chemical: bme680: Fix overflows in compensate() functions\r\n\r\nThere are cases in the compensate functions of the driver that\nthere could be overflows of variables due to bit shifting ops.\nThese implications were initially discussed here [1] and they\nwere mentioned in log message of Commit 1b3bd8592780 (\u0026quot;iio:\nchemical: Add support for Bosch BME680 sensor\u0026quot;).\r\n\r\n[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emux: improve patch ioctl data validation\r\n\r\nIn load_data(), make the validation of and skipping over the main info\nblock match that in load_guspatch().\r\n\r\nIn load_guspatch(), add checking that the specified patch length matches\nthe actually supplied data, like load_data() already did.(CVE-2024-42097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: Fix potential illegal address access in jffs2_free_inode\r\n\r\nDuring the stress testing of the jffs2 file system,the following\nabnormal printouts were found:\n[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948\n[ 2430.649622] Mem abort info:\n[ 2430.649829]   ESR = 0x96000004\n[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2430.650564]   SET = 0, FnV = 0\n[ 2430.650795]   EA = 0, S1PTW = 0\n[ 2430.651032]   FSC = 0x04: level 0 translation fault\n[ 2430.651446] Data abort info:\n[ 2430.651683]   ISV = 0, ISS = 0x00000004\n[ 2430.652001]   CM = 0, WnR = 0\n[ 2430.652558] [0069696969696948] address between user and kernel address ranges\n[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33\n[ 2430.655008] Hardware name: linux,dummy-virt (DT)\n[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2430.656142] pc : kfree+0x78/0x348\n[ 2430.656630] lr : jffs2_free_inode+0x24/0x48\n[ 2430.657051] sp : ffff800009eebd10\n[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000\n[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000\n[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14\n[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000\n[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000\n[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19\n[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14\n[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302\n[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342\n[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000\n[ 2430.664217] Call trace:\n[ 2430.664528]  kfree+0x78/0x348\n[ 2430.664855]  jffs2_free_inode+0x24/0x48\n[ 2430.665233]  i_callback+0x24/0x50\n[ 2430.665528]  rcu_do_batch+0x1ac/0x448\n[ 2430.665892]  rcu_core+0x28c/0x3c8\n[ 2430.666151]  rcu_core_si+0x18/0x28\n[ 2430.666473]  __do_softirq+0x138/0x3cc\n[ 2430.666781]  irq_exit+0xf0/0x110\n[ 2430.667065]  handle_domain_irq+0x6c/0x98\n[ 2430.667447]  gic_handle_irq+0xac/0xe8\n[ 2430.667739]  call_on_irq_stack+0x28/0x54\nThe parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of\nthe jffs_inode_info structure. It was found that all variables in the jffs_inode_info\nstructure were 5a5a5a5a, except for the first member sem. It is suspected that these\nvariables are not initialized because they were set to 5a5a5a5a during memory testing,\nwhich is meant to detect uninitialized memory.The sem variable is initialized in the\nfunction jffs2_i_init_once, while other members are initialized in\nthe function jffs2_init_inode_info.\r\n\r\nThe function jffs2_init_inode_info is called after iget_locked,\nbut in the iget_locked function, the destroy_inode process is triggered,\nwhich releases the inode and consequently, the target member of the inode\nis not initialized.In concurrent high pressure scenarios, iget_locked\nmay enter the destroy_inode branch as described in the code.\r\n\r\nSince the destroy_inode functionality of jffs2 only releases the target,\nthe fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)\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: mlxreg: 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-42129)\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\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\ndrm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc\r\n\r\nInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.\nV2: To really improve the handling we would actually\n   need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)",
  "id": "OESA-2024-1960",
  "modified": "2026-08-06T11:07:25Z",
  "published": "2024-08-09T11:07:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33619"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35247"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35848"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36890"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38556"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38576"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38600"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38606"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38617"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39471"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39473"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39481"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39486"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39493"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39496"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39503"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40908"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40921"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40953"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40962"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40967"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41010"
    },
    {
      "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-41018"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41020"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41023"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41039"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41040"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41041"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41045"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41048"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41049"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41056"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41062"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41064"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41069"
    },
    {
      "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-41074"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41075"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41077"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41080"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41090"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42068"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42086"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42115"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42126"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42129"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42155"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42162"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42228"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-33619",
    "CVE-2024-35247",
    "CVE-2024-35848",
    "CVE-2024-35859",
    "CVE-2024-35966",
    "CVE-2024-36890",
    "CVE-2024-36896",
    "CVE-2024-36899",
    "CVE-2024-36901",
    "CVE-2024-36944",
    "CVE-2024-36964",
    "CVE-2024-38556",
    "CVE-2024-38576",
    "CVE-2024-38600",
    "CVE-2024-38606",
    "CVE-2024-38607",
    "CVE-2024-38617",
    "CVE-2024-39471",
    "CVE-2024-39473",
    "CVE-2024-39475",
    "CVE-2024-39481",
    "CVE-2024-39486",
    "CVE-2024-39493",
    "CVE-2024-39496",
    "CVE-2024-39503",
    "CVE-2024-40900",
    "CVE-2024-40906",
    "CVE-2024-40908",
    "CVE-2024-40913",
    "CVE-2024-40920",
    "CVE-2024-40921",
    "CVE-2024-40922",
    "CVE-2024-40935",
    "CVE-2024-40953",
    "CVE-2024-40962",
    "CVE-2024-40967",
    "CVE-2024-40981",
    "CVE-2024-41006",
    "CVE-2024-41010",
    "CVE-2024-41013",
    "CVE-2024-41014",
    "CVE-2024-41018",
    "CVE-2024-41019",
    "CVE-2024-41020",
    "CVE-2024-41021",
    "CVE-2024-41023",
    "CVE-2024-41039",
    "CVE-2024-41040",
    "CVE-2024-41041",
    "CVE-2024-41044",
    "CVE-2024-41045",
    "CVE-2024-41048",
    "CVE-2024-41049",
    "CVE-2024-41056",
    "CVE-2024-41062",
    "CVE-2024-41063",
    "CVE-2024-41064",
    "CVE-2024-41069",
    "CVE-2024-41072",
    "CVE-2024-41073",
    "CVE-2024-41074",
    "CVE-2024-41075",
    "CVE-2024-41076",
    "CVE-2024-41077",
    "CVE-2024-41080",
    "CVE-2024-41085",
    "CVE-2024-41090",
    "CVE-2024-41091",
    "CVE-2024-41096",
    "CVE-2024-42068",
    "CVE-2024-42086",
    "CVE-2024-42097",
    "CVE-2024-42115",
    "CVE-2024-42126",
    "CVE-2024-42129",
    "CVE-2024-42155",
    "CVE-2024-42162",
    "CVE-2024-42228"
  ]
}